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I. REAL PARTY IN INTEREST 

The real party in interest is the assignee of the full interest in the invention, 
Sonics, Inc., 2440 W. El Camino Real, Suite 620, Mountain View, California 
94040. 

II. RELATED APPEALS AND INTERFERENCES 

To the best of Appellant's knowledge, there are no appeals or 
interferences related to the present appeal that will directly affect, be directly 
affected by, or have a bearing on the Board's decision in the instant appeal. 

III. STATUS OF THE CLAIMS 

Claims 1-36 are pending in the application and were finally rejected in an 
Office Action mailed March 11, 2005. Claims 11-3, 17-19, 28-30, 35 and 36 
stand objected to. Claims 1-36 are the subject of this appeal. A copy of Claims 
1-36, as they stand on appeal are set forth in an Appendix of Claims. Appellant 
notes that these claims are presented as amended in Appellant's Response to 
Final Office Action, filed July 11, 2005. Claims 1-36 are being appealed. 

IV. STATUS OF AMENDMENTS 

An amendment was filed on July 1 1 , 2005, subsequent to the Final Office 

Action mailed March 1 1 , 2005. The Examiner confirmed the final rejection of 
these claims in an Advisory Action mailed August 08, 2005 (hereinafter "Advisory 
Action"). A copy of all claims on appeal is attached hereto as an Appendix of 
Claims. 

Appellant respectfully traverses each of these grounds of rejection. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

According to one embodiment, a method for communicating data between 

functional blocks in a computing device in a multi-threading system is described 
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in independent claim 1. The method establishes a thread identifier for each 
independent data stream between an initiator functional block and a target 
functional block. (Specification at page 7, If 0012; page 8 If 0013; page 32 If 
0077.) A plurality of independent data streams exist between a first initiator 
functional block and a first target functional block. (Specification at page 34 
0084; page 39 If 0095-0096; figure 4 and 12.) The method further includes a 
condition wherein, if the first target functional block is unable to accept a data 
transfer from the first initiator functional block, the first target functional block 
issues a busy signal identified by the thread identifier to the first initiator. 
(Specification at page 1 9 If 0052; page 24 If 0059; page 25 If 0062; page 33 If 
0079-0080.) The method further states that the first initiator functional block 
withholds the issuing of data transfers associated with the thread identifier in 
response to the issued busy signal. However, the first initiator may issue data 
transfers that are not associated with the thread identifier identified by the issued 
busy signal to the first target. (Specification at page 23 If 0058; page 24 0059- 
0060; page 25 If 0062.) Lastly, the method includes the mapping of a data flow 
from the initiator functional block to the target functional block to a thread 
indicated by the thread identifier to meet a service guarantee on a per thread 
identifier basis (Specification at page 21 If 0054;page 37 If 0090-0092; page 40 If 
0098-0099; page 43 1f 01 08-01 10; figure 15a, 15b, 17, 19 and 21.) Thus, 
multiple data streams can exist at any given time between the first initiator and 
the first target. Each data stream has its own thread identifier. Even though the 
first target indicates its busy on a first thread identifier, the first initiator still issues 
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data transfers to that first target on different data streams with other thread 
identifiers. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

I. Claims 1-10, 14-16, 20-27 and 31-34 stand rejected under 35 U.S.C. 
§1 03(a) as being obvious over U.S. Patent Number 5,274,783 (hereinafter 
"House") in view of U.S. Patent Number 6,002,692 (hereinafter 'Wills"), For 
purposes of this appeal, claims 1-36 stand and fall together as Group I. 

VII. ARGUMENT 

A. CLAIM GROUP I: APPLICANT'S TRAVERSE THE EXAMINER'S 
CONCLUSIONS ON THE MEANING CONVEYED WITH THE TERMS 
"THREADS", "THREAD ID'S" AND "DATA STREAM AS WOULD BE 
UNDERSTOOD BY ONE SKILLED IN THE ART." 

Overall, a reference used by the office action named House discloses a 
single threaded system that provides a protocol and format for communications 
within a system. In a single threaded system, as one data stream thread is 
completed between a target and an initiator, then in a sequential fashion a 
second data stream may be initiated between those same two devices. In multi- 
threading systems, a single source device/application may have two or more 
threads of data streams in progress at the same time between itself and a target. 
In multi-threading systems, when an initiator receives a response from a 
particular target, the initiator must know more than just the source ID of target to 
figure out what data stream this response belongs to. Multiple data streams may 
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be occurring between the initiator and target at the same time. The initiator 



should also know the thread id of the data stream that the response from the 

target came from. The office action tries to stretch the interpretation of the terms 

in applicant's claims so that the single threaded system disclosed by House can 

be used to satisfy clearly stated limitations in applicant's claims. 

Claim 1 in its context and entirety states: 

A method for communicating data between functional blocks in a 
computing device, comprising: 

establishing a thread identifier for each independent data 
stream between an initiator functional block and a target functional 
block, wherein a plurality of independent data streams exist 
between the initiator functional block and the target functional 
block, 

if the target functional block is unable to accept a data transfer 
from the initiator functional block, the target functional block 
issuing a busy signal identified by the thread identifier; 

the initiator functional block withholding issuance of data 
transfers associated with the thread identifier in response to the 
issued busy signal, wherein data transfers not associated with the 
thread identifier identified by the issued busy signal may be 
issued; and 

mapping a data flow from the initiator functional block to the 
target functional block to a thread indicated by the thread identifier 
to meet a service guarantee on a per thread identifier basis. 



Appellant submits that the Examiner has improperly construed definitions 

of the terms "threads", "thread IDs" and "data stream." The Examiner stated: 

Examiner notes that it is the Applicant's claims [words?] as 
stated in the Applicant's claims that are being rejected with prior 
art. For example, the " data streams" of claim 1 is interpreted as 
a 'signals' . Signals being transmitted are information. They can 
be spoken words such as telephone conversation , music, or 
even computer data, 'thread identifier 1 is interpreted as 
Connection identifier* or unique identifier, all of these terms are 
well known in the inter-process communication art. 
(Office Action dated 3-1 1-05, page 8) 
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Appellant traverses the Examiner's stated conclusions on the meaning of the 
terms "threads" and "thread Ids" with evidence from various dictionaries and 
articles by people skilled in the art concerning what the above terms generally 
convey. Appellant submits definitions of the term "thread" from the following four 
technical websites and one standards body: 1) Geek.com; 2) Whatis.com; 3) 
Webopedia.com; 4) Techweb.com; and 5) the Open Core Protocol Specification 
version 2.0 published by the OCP-IP standards organization. Appellant submits 
articles on multi-threading from: 1) Sun Microsystems' article on multi-threading 
that discusses threads in JAVA software environment; 2) a Computer 
Programming Thread FAQ; and 3) again the Open Core Protocol Specification 
version 2.0 published by the OCP-IP standards organization. The entire Open 
Core Protocol Specification document is relevant to person's skilled in the art in 
an understanding of the above terms but appellant specifically directs the 
Examiner's attention to pages 10, 19, 20, and 46 of this large document. 

The seven references discussing threads and multi-threading all differ 
slightly but convey a common theme. The theme is that a "thread" can be 
thought of as 1) a series of communication exchanges, usually involving data, in 
a related transaction between an initiating device to a target device and/or 2) a 
part of a single program that runs independently and/or simultaneously along 
with other threads from that program to accomplish a specific task. Either way, a 
single source device/application may have two or more threads of data streams 
in progress at the same time between itself and a target. 
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Appellant submits that the Examiner's definition of 'thread identifier 1 as 
being interpreted as 'connection identifier 1 or unique identifier is incorrect. A 
thread identifier identifies a thread, whereas a connection identifier and a unique 
identifier can encompass a much different meaning. For example, a unique 
identifier could be used to identify anything at all, from a vehicle identification 
number to a cellular phone's serial number. A connection identifier may identify a 
source address and a target address. However, a connection identifier may not in 
all cases uniquely identify the particular data stream thread occurring between 
that source address and target address. Hence, Appellant submitted the 
definitions to show that one reasonably skilled in the art would not reasonably 
equate a thread id associated with a data stream in a multi-threaded system with 
a unique identifier associated with spoken words in a telephone conversation. 
(See Examiner's assertion in Office Action dated 3-1 1-05, pages 6-8) 

Similarly, appellant traverses the Examiner's stated conclusions on the 
meaning of "data stream" with evidence from various dictionaries by people 
skilled in the art concerning what the term generally conveys. Appellant submits 
definitions of the term "data stream" from the following technical website, 
standards body, and the Wills reference cited by the Examiner in the two 
previous office actions: 1) Techweb.com; 2) the American National Standard's 
Telecom glossary; and 3) the Wills reference describes a SONET STS-48 data 
stream at Col. 4 Line 62 to Col. 5 Line 14. 

The three references discussing the term "data stream" all differ slightly 
but convey a common theme. The theme is that a "data stream" can be thought 
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of as "a sequence of encoded information in a transmission from one place to 
another." 

Appellant submits that the Examiner's narrow definition of 'data stream 1 as 
being interpreted as 'signals 1 is incorrect. The Examiner's statement that, 
"Signals being transmitted are information. They can be spoken words such as 
telephone conversation , music, or even computer data" is too broad of a 
meaning, going far beyond the narrower definition of "a sequence of encoded 
: information in a transmission from one place to another." 

Appellant submitted the above definitions for the three terms being 
discussed in the Response after Final Rejection, dated 06/1 1/05. 

B. CLAIM GROUP I: BASED ON A REASONABLE INTERPRETATION OF 
THE TERMS "THREADS", "THREAD ID'S" AND "DATA STREAMS", THE 
COMBINATION OF HOUSE AND WILLS DO NOT MAKE CLAIMS 1-10, 14-16, 
20-27 AND 31-34 OBVIOUS UNDER 35 U.S.C. §103. 

1. The office action fails to make an adequate rejection under 35 
U.S.C. §103 pointing out how the references make applicant's claims 
obvious. 

The office action rejects claims 1-10, 14-16, 20-27, and 31-34 under 35 
U.S.C. § 103(a) as being unpatentable over House in view of Wills. The 
Examiner states: 
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Applicant's arguments filed 10/21/2004 have been fully 
considered but they are not persuasive. 
In the remarks applicants argued: 

A. House does not disclose the existence of multiple 
independent data. 

B. House does not disclose establishing the thread 
identifier for each independent data stream. 

C. House does not disclose actually issuing data transfers 
not associated with thread identifier. 



Examiner notes that while specific references were made to the 
prior art, it is actually also the prior arts in its entirety and the 
combination of the prior arts in its entirety that is being referred 
to. 

(Office Action dated 3-1 1-05, pages 6-8) 



However, applicant respectfully asserts that claim 1, as amended, is not obvious 

under 35 U.S.C. § 103(a) in view of the combination of House with Wills. 

The law requires: 

To establish a prima facie case of obviousness, there must be 
some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of 
ordinary skill in the art, to modify the reference or to combine 
reference teachings. In re Vaeck, 947 F.2d 488, 20 USPQ2d 
1438 (Fed. Cir. 1991). (Manual of Patent Examining Procedure U 
2143). 



Further, the law also requires: 

To establish prima facie obviousness of a claimed invention, all 
the claim limitations must be taught or suggested by proposed 
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combination of the prior art. In re Royka, 490 F.2d 981 , 180 
USPQ 580 (CCPA 1974). (Manual of Patent Examining 
Procedure (MPEP) 2143.03). 

The first point in patent law requires the combination of the references 
themselves to disclose each and every limitation in applicant's claims to render 
those claims obvious under section 103. Further, the Examiner is required to . 
particularly point out where these limitations are disclosed in the prior art 
document. Thus, if the office action makes a specific reference to where a claim 
limitation is disclosed in prior art document and in fact that limitation is not 
disclosed in that reference, then the office action is not satisfying the 
requirements of section 103. Also, a limitation maybe inherently disclosed under 
103 if the Examiner makes a proper evidentiary finding. The PTO may establish 
that one of ordinary skill in the art would have been motivated to combine the 
references with articulated findings of fact regarding: 1) the level of skill in the art; 
2) the relationship between the fields of the cited art; and 3) the particular 
features of the prior art references that would motivate one of ordinary skill in 
applicant's particular art to select elements disclosed in references from a wholly 
different field. In re Dembiczak , 175 F.3d 994, 996 (Fed. Cir. 1999). However, 
the office action's statement "Examiner notes that while specific references were 
made to the prior art, it is actually also the prior arts in its entirety and the 
combination of the prior arts in its entirety that is being referred to" does not 
satisfy that evidentiary requirement. The above statement does not either 1 ) 
makes a specific reference to where the limitation is found in a specific reference 
document or 2) make a proper evidentiary finding of fact. 
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2. House discloses a single threaded communication system 
that does not disclose the existence of multiple independent data 
streams between an initiating device and a target device. 

The law requires: 

To establish prima facie obviousness of a claimed invention, all 
the claim limitations must be taught or suggested by proposed 
combination of the prior art. In re Royka, 490 F.2d 981 , 180 
USPQ 580 (CCPA 1974). (Manual of Patent Examining 
Procedure (MPEP) 2143.03). 



Appellant submits that House fails to disclose the existence of multiple 
independent data streams occurring concurrently between two functional blocks. 
In contrast, House merely discloses a bus extender which contains transfer and 
logic circuitry that implement a single data stream between devices. House 
discloses: 

In particular, the transfer and logic circuitry (i) receives first 
connection-control signals from one of the buses, which signals 
have fields of data designating the extender as the addressee and 
designating the source of the signals : (ii) identifies the ultimate 
target for the inter-bus communication based on data contained in 
the first connection-control signals, or, depending on the direction 
of the communication, stored in a latch within the extender itself; 
(iii) generates second connection-control signals including fields of 
data designating the extender as the source of the communication 
and the ultimate target; and (iv) provides these latter signals to the 
appropriate transceiver for transmission over the other bus . 
(House, col. 2, lines 40-53) (emphasis added) 

House discloses a method for creating a single data stream between 

devices connected to an auxiliary bus and a main bus. Each 

communication originating from a device connected to the auxiliary bus to 
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the main bus is processed by the transfer and logic circuitry as detailed 
above. House discloses how to set up a single data stream between two 
devices; however, House is silent about multiple data streams can exist 
between on device and another. House does not disclose any details like 
assigning multiple thread ids because multiple independent data stream 
may exist. House is silent about these details because House does not 
disclose or suggest the existence of multiple independent data streams 
between one device and another. House merely discloses that all data 
originating from one device and having the same destination is processed 
in the same fashion. Therefore, House does not disclose "a plurality of 
independent data streams" between a device on the auxiliary bus and the 
main bus. 

3. House does not disclose establishing a thread identifier for 
each independent data stream between two functional blocks. 

Appellant submits that House fails to disclose establishing a thread 

identifier for each independent data stream between two functional blocks. 

In contrast, House merely discloses assigning a single identification code to 

a device connected to the main bus. House discloses: 

[T]he bus extender takes advantage of dual-tier, hierarchal 
addressing used in the SCSI standards to direct messages to the 
designated devices on the other bus. In the addressing scheme 
employed in the invention, each device connected to either the 
main or auxiliary bus is identified by a unique identification code 
("ID"). In addition, each device ID is associated with an auxiliary 
identification or address-descriptor, which in the SCSI standards 
is referred to as a LUN or logical unit number. 
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For purposes of communication, the bus extender has an ID on 
both the main and auxiliary buses. 

In order to pass messages received over the main bus from a host 
computer, i.e., during SELECTION, the extender first converts the 
LUN field data of the connection-control signals received over the 
main bus to the ID of the target on the auxiliary bus, and supplies 
the extender's own auxiliary-bus ID as the initiator ID in the 
auxiliary-bus connection-control signals. 
(House, col. 2, lines 54 through col. 3 line 9) (emphasis added) 

Accordingly, House discloses that a device has a single ID 

associated with it. House does not disclose " establishing a thread identifier 

for each independent data stream between an initiator functional block and 

a target functional block, wherein a plurality of independent data streams 

exist between the initiator functional block and the target functional block." 



4. House does not disclose the issuance of data transfers not 
associated with the busy thread identifier from the initiator while 
withholding issuance of data transfers associated with the busy 
thread identifier. 

The Examiner continuously cites House at Col. 9 Lines 10-36 as 

disclosing "the initiator functional block withholding issuance of data transfers 

associated with the thread identifier in response to the issued busy signal, 

wherein data transfers not associated with the thread identifier identified by the 

issued busy signal may be issued." Specifically, the Examiner states: 

if the target functional block is unable to accept a data transfer 
from the initiator functional block (col. 9, lines 10-25), the target 
functional block issuing a busy signal identified by the thread 
identifier (col. 9, lines 25-36); 
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the initiator functional block withholding issuance of data 
transfers associated with the thread identifier in response to the 
issued busy signal (col. 9, lines 20-36), wherein data transfers not 
associated with the thread identifier identified by the issued busy 
signal may be issued (col. 9, lines 25- 36) 
(Office Action dated 3-1 1-05, page 7) 



Applicants assert the House does not disclose that the same initiator 
withholds issuance of data transfers associated with the busy thread identifier 
and allows the issuance of data transfers from a data stream that are not 
associated with the busy thread ID. In contrast, House merely discloses 
arbitration between two devices to obtain control of a bus and the subsequent 
establishment of a communication link between the initiating host and a target. 
The control logic allows the establishment of a communication link between the 
first initiating device and a first target while issuing a busy signal and blocks 
transactions from any additional initiating devices. 

Accordingly, House discloses arbitration between two devices, a host 

computer 14 and an extender 30 to obtain control of a bus: 

To transfer messages, the host computer 14 attempts to gain 
control of the main bus 26 during what is called the 
ARBITRATION phase by asserting the BUSY line ("bsy") at "a" 
in part 7A of the drawing, and asserting the host computer's 
own ID on the data lines ("dbn") at "b." (In SCSI buses, there 
are, e.g., eight data lines, one corresponding to each of the ID's 
(i.e., ID. sub.-- 0-ID.sub.- 7) that can be assigned to devices on 
the bus. Thus, for example, to assert ID.sub.- 6, the sixth data 
line is driven HIGH.) 

If at the time the host computer 14 is attempting to control the 
main bus 26, any other device or devices are likewise 
attempting to do so. the bus is deemed to be in contention. In 
that case, according to the SCSI standards, the contending 
device with the highest ID is given priority. Thus, for example, if 
the extender 30 were also attempting to control the main bus 
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26, the control logic 50 would assert BUSY and the extender's 
ID, i.e., ID. sub.-- 0, on the data lines. Since, the computer's 
ID.sub.-- 6 is higher than the extender's ID. sub.-- 0, the 
extender 30 would fall off the main bus 26, and the host 
computer 14 would gain control of the main bus 26 by asserting 
the SELECT line ("sel"). If there are no contenders for the bus, 
then the host computer 14 simply can assert "sel," as shown at 
"c." This finishes the main-bus ARBITRATION phase. 
(House Col. 8 Ln. 62 to Col. 9 Ln. 9) 



Next, House discloses that the initiating device, host computer 14, 

establishes a communication link with a target, one of the auxiliary-bus peripheral 

devices 24. A busy signal is asserted on the main bus during the establishment 

of this communication link. House discloses: 

Now, the host computer 14 attempts to establish a 
communication link with a target on the main bus 26 within 
what is called the SELECTION phase by sending a first 
connection control signal over the data lines ("dbn") as shown 
at "d," which signal gives both the host computer's own ID as 
the initiator and the target's ID on the main bus 26 . 
Consequently, two of the data lines are asserted--the two 
corresponding to the host computer and the target. In addition, 
the correct parity for the asserted data bits, i.e., in this case, a 
HIGH value, is maintained on the data parity line ("dbp"). In 
other words, dbp is asserted at "e.'\ Moreover, another signal 
line, the I/O control line ("i/o"), is deasserted to indicate 
SELECTION. (Assertion of the i/o line indicates 
RESELECTION.) Afterwards, the initiator also deasserts BUSY 
at "f." 

In order to illustrate the invention, we will assume that the 
target ID asserted during SELECT is that of the bus extender 
30, e.g., ID.sub.- 0, which means that the host computer 14 is 
attempting to communicate with one of the auxiliary-bus 
peripheral devices 24 . Accordingly, during SELECT, the control 
logic 50 of the extender 30 identifies the target as ID.sub.- 0, 
and verifies that SELECT is asserted and that BUSY is 
deasserted. In addition, the control logic 50 verifies that the 
parity is correct, and that there are two, and only two, bits 
asserted on the dbn lines. 
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Once the extender 30 has confirmed that it is the target, the 
extender accepts SELECTION by asserting BUSY on the main 
bus 26, as shown at point "g" in FIG. 5. In response to the 
acceptance, the host computer 14 de-asserts SELECT at "h." 
(House Col. 9 Lines. 10-41) 

Appellant asserts that House, in the above section cited by the Examiner, 
does not disclose that the same initiator withholds issuance of data transfers 
associated with the busy thread identifier and allows the issuance of data 
transfers from a data stream that are not associated with the busy thread ID. To 
reiterate, House merely discloses arbitration between two devices to obtain 
control of a bus. House then discloses the subsequent establishment of a 
communication link between the initiating host and a target while issuing a busy 
signal and blocks transactions from any additional initiating devices. 

On page 2 of the advisory action dated 08/08/05, the Examiner states: 

Regarding House not teaching data transfer between target and 
initiator. Applicant's attention is drawn to elements of figs 5 and 6 of 
[the] House reference in which the busy signal asserted, while other 
data lines transferring data/messages (col. 9, lines 26-67). 

Appellant submits that House teaches data transfer in general. As stated above, 

House merely teaches arbitration between two devices to obtain control of a bus. 

House then discloses the subsequent establishment of a communication link 

between the initiating host and a target. Such communication is that of single 

threaded data transfers and not multi-threaded data transfers. Therefore, the 

data transfers taught by House are insufficient. 
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5. Wills does not disclose meeting service guarantees on a per 
thread identifier basis. 

Appellant submits that Wills does not disclose meeting service guarantees 

on a per thread identifier basis . In contrast, Wills merely discloses: 

The converter also splits the traffic into multiple priorities so as to 
assure quality of service (QoS) for timing critical traffic. 
(Wills, col. 5, lines 19-21) 

Wills merely discloses a method for ensuring quality of service by solely 

prioritizing traffic. Wills discloses splitting traffic to meet a quality of service 

guarantee, but does not differentiate between two data streams originating from 

the same functional block yet belonging to two different thread identifiers. 

Hence, Wills does not teach, suggest or disclose meeting service guarantees on 

a per thread basis. 

C. CLAIM GROUP I: NO MOTIVATION EXISTS TO COMBINE HOUSE 
WITH WILLS TO ACHIEVE THE ELEMENTS OF APPELANTS' INVENTION. 

Appellant submits that the Examiner has provided inadequate motivation 

to properly combine the references, House and Wills, under 35 U.S.C. § 103. 
Patent law requires that the evidence for the motivation to combine references 
under 35 U.S.C. § 103 must come from either 1 ) within the references 
themselves or 2) make articulated findings of fact regarding: A) the level of skill in 
the art; B) the relationship between the fields of the cited art; and C) the 
particular features of the prior art references that would motivate one of ordinary 
skill in applicant's particular art to select elements disclosed in references. See 
In re Lee . 277 F.3d 1338, 1344 (Fed. Cir. 2002), In re Thrift , 298 F.3d 1357, 1361 
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(Fed. Cir. 2002), In re Dembiczak , 175 F.3d 994 (Fed. Cir. 1999), and the Manual 

of Patent Examining Procedure section 2143. The Examiner merely states that: 

House does not specifically discloses to meet a service guarantee 
on a per thread identifier basis. However, Will discloses to meet a 
service guarantee on a per thread identifier basis (col. 5, lines 19- 
34). 

Therefore, it would have been obvious to one of ordinary skill in 
the art at the time of the invention was made to combine Will with 
House because it would provide a guaranteed throughput. 
(Office Action dated 3-1 1 -05, pages 3-4) 

Paraphrasing the above language, Reference A does not disclose limitation X but 

Reference B does and it's obvious to combine them to achieve a result, 

presumed by law, found in applicant's patent application. The Examiner cites to 

no hints or suggestions in either reference that explicitly or implicitly suggests the 

combination of these two references. The Examiner fails to make an articulated 

finding of fact. Therefore, on this basis alone, applicant respectfully submits that 

a presumed impressible use of hindsight has occurred and the obviousness 

rejection of claims 1-10, 14-16, 20-27 and 31-34 has been overcome. 



D. APPELLANT CORRECTLY ESTABLISHES A CORRELATION 
BETWEEN THE CLAIMED INVENTION AND DEFINITIONS FOR THREADS', 
THREAD ID'S' AND 'DATA STREAM.' 

On page 2 of the advisory action dated 08/08/05, the Examiner states: 

Applicant failed to establish correlation between claimed invention 
and definitions. Applicant fails to point out where the threading 
model clearly and concisely described/enabled/implemented/used 
in the specification as it is defined in cited definitions after the final 
rejection. 
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Appellant submits that there is a proper correlation between the claimed 
invention and the definitions of "threads", "thread IDs" and "data streams" as 
defined in the response dated 06/1 1/05 and restated in the current appeal brief. 
Applicants assert that a nexus properly exists between the definitions above and 
the claims. On page 8 of the office action dated 03/1 1/05, the Examiner offers 
definitions for the terms "threads", "thread IDs" and "data stream" that were in 
contrast with what appellant generally believes one reasonably skilled in the art 
would understand that these terms convey. Appellant believes these definitions 
to be incorrect and submitted what appellant believes generally to be the correct 
definitions used by others skilled in the art, by citing to numerous, widely used 
technical references. Hence the correlation between the cited definitions and the 
claims are relevant since the terms "threads", "thread IDs" and "data streams" are 
used directly in the claims. For example, claim 1 uses these three terms 9 times. 
Thus, a nexus properly exists between the submitted definitions for the terms in 
dispute and the current claims in this office action. 

Appellant submits that terms used in the claims are given its ordinary 
meaning as known to others skilled in the art, unless a contrary definition is 
described in the specification. Appellant's specification does not created special 
definitions for the three terms above. Instead the appellant relied on the ordinary 
meaning of these terms as known to other skilled in the art. The citations to the 
external references only attempt to show a general meaning of what the ordinary 
meaning of these terms are known by other skilled in the art. 



Serial No. 09/802,405 



-20- 



Atty. Dkt. 02998.P013 



E. APPELLANT'S ARGUMENTS PROPERLY COMPLY WITH C.F.R. 
§1.1 11(C). 

On page 2 of the advisory action dated 08/08/05, the Examiner states: 

Applicant's arguments do not comply with 37 C.F.R. §1.1 1 1(c) 
because they do not clearly point out the patentable novelty which 
he or she thinks the claims present in view of the state of the art 
disclosed by the references cited or the objections made. 

Appellant's are confused by this statement. Appellant's responses dated 

10/21/04 and 06/1 1/05 specifically lists multiple reasons why the claims present 

patentable novelty over the state of the art disclosed by House and Wills. The 

Examiner acknowledged the relevance of the arguments when the Examiner 

stated "Applicant's arguments filed 10/21/2004 have been fully considered but 

they are not persuasive. (Office Action dated 6-1 1-05 page X). Moreover, the 

examiner then summarized the relevance of appellant arguments. These 

reasons have again been recited in the arguments section of this appeal brief. 

Specifically, the amendments address the following distinctions between the 

claims and the cited references: 

1 . House does not disclose the existence of multiple independent 
data streams between an initiating device and a target device. Office 
Action Response dated 10/21/04, page 15 and Office Action 
Response dated 06/11/05, page 19, last paragraph. 

2. House does not disclose establishing the thread identifier for each 
independent data stream. Office Action Response dated 10/21/04, 
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page 16 and Office Action Response dated 06/1 1/05, page 19, last 
paragraph. 

3. House does not disclose the issuance of data transfers not 
associated with the busy thread identifier from the initiator while 
withholding issuance of data transfers associated with the busy 
thread identifier. Office Action Response dated 10/21/04, page 16-18 
and Office Action Response dated 06/1 1/05, page 16-19. 

4. Wills does not disclose meeting service guarantees on a per thread 
identifier basis. Office Action Response dated 10/21/04, page 18 and 
Office Action Response dated 06/11/05, page 19, last paragraph. 
Thus, Applicant's arguments clearly comply with 37 C.F.R. §1.1 11(c) by 

clearly point out the patentable novelty which he or she thinks the claims present 
in view of the state of the art disclosed by the references cited. 

F. PRAYER FOR RELIEF. 

With all due respect, the prosecution of this case on its merits has been 
exhausted. Appellant respectfully request that the Appeal Board use its authority 
to allow these claims. In the previous responses, the applicant responded to the 
same issues as well as unwarranted 35 USC 112 rejections. In other responses, 
the applicant has over came a different set of cited prior art references. The 
claims have not changed since the last response to an office action and no 
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meaningful examination is occurring in this case. Appellant respectfully submits 
for all of the reasons discussed above claims 1-36 should be allowed. 
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IX. CONCLUSION 



For the reasons stated above, the rejection of claims 1-10, 14-16, 20-27 
and 31 -34 under 35 U.S.C. § 1 03(a) of House over Wills should be withdrawn. 
Appellant respectfully requests that the Board reverse the rejections of the claims 
under 35 U.S.C. §1 03(a), and since there are no remaining grounds of rejection 
to be overcome, direct the Examiner to enter a Notice of Allowance for Claims 1- ■ 
36. 

Fee for Filing a Brief in Support of Appeal 

Enclosed is a check in the amount of $620.00 to cover the fee for filing a 
brief in support of an appeal as required under 37 C.F.R. § 1.17(c) and 
41 .20(b)(2) as well as the fee for a one month extension. Appellant believes that 
a one month extension is all that is necessary under 37 C.F.R. § 41 .39(b). For 
appellant believes that the Examiner's answer in their advisory action dated 
08/08/2005 contains rejections designated as a new ground of rejection. Under 
rule 41 .39(b), the time for response is set for two months from the date of the 
Examiner's answer. In this case, that date for reply is 10/08/05. 

Deposit Account Authorization 

Authorization is hereby given to charge our Deposit Account No. 02-2666 
for any charges that may be due. Furthermore, if an additional extension is 
required over the one-month extension already included, then Appellant hereby 
requests such extension. 



Respectfully submitted, 



BLAKELY, SOKOLOFF, 
TAYLOR & ZAFMAN LLP 





12400 Wilshire Boulevard 
Seventh Floor 

Los Angeles, CA 90025-1026 
(303)740-1980 



Aslam A. Jaffery 
Attorney for Appellant 
Registration No. 51,841 
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IX. APPENDIX OF CLAIMS (37 C.F.R. S 41,37(cU1Mviii)) 



The claims on appeal read as follows: 

1 . (Previously Presented) A method for communicating data 
between functional blocks in a computing device, comprising: 

establishing a thread identifier for each independent data stream 
between an initiator functional block and a target functional block, wherein a 
plurality of independent data streams exist between the initiator functional block 
and the target functional block, 

if the target functional block is unable to accept a data transfer from 
the initiator functional block, the target functional block issuing a busy signal 
identified by the thread identifier; 

the initiator functional block withholding issuance of data transfers 
associated with the thread identifier in response to the issued busy signal, 
wherein data transfers not associated with the thread identifier identified by the 
issued busy signal may be issued; and 

mapping a data flow from the initiator functional block to the target 
functional block to a thread indicated by the thread identifier to meet a service 
guarantee on a per thread identifier basis. 

2. (Original) The method as set forth in claim 1 , wherein the busy 
signal comprises a signal that is maintained active when the target functional 
block is unable to accept data transfers. 
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3. (Original) The method as set forth in claim 1 , wherein the busy 
signal comprises a credit signal used to communicate a number of credits that 
indicate how many data transfers the target functional block can accept. 

4. (Original) The method as set forth in claim 3, further comprising 
decrementing the number of credits for each active data transfer and 
incrementing the number of credits upon freeing up of resources for further data 
transfers. 

5. (Original) The method as set forth in claim 3, wherein the credit 
signal is generated by maintaining the signal in an active state for a number of 
clock cycles corresponding to the number of credits. 

6. (Previously Presented) The method as set forth in claim 3, 
wherein the credit signal comprises a multi-bit coded signal indicative of the 
number of credits. 

7. (Original) The method as set forth in claim 1 , further comprising 
determining service guarantees for at least one transaction stream between 
initiator functional blocks and the target functional blocks. 
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8. (Original) The method as set forth in claim 1 , further comprising 
the initiator functional block stopping to send data transfers so that the target 
functional block receives no more than a determined number of data transfers 
after issuance of the busy signal. 

9. (Original) The method as set forth in claim 1 , wherein the target 
functional block issues a busy signal no more than a determined number of clock 
cycles after the target functional block determines that it has insufficient buffer 
space to receive data transfers from an initiator functional block. 

10. (Original) The method as set forth in claim 8, further comprising 
the target device buffering the data transfers received after issuance of the busy 
signal until resources become available to service the buffered data transfers. 

1 1 . (Original) The method as set forth in claim 7, wherein 
determining service guarantees comprises: 

mapping the transaction stream to data channels of components between 
an initiator device and target device; 

converting performance guarantees of selected data channels of the 
mapped transaction stream such that the guarantees of the data channels are 
aligned to be uniform in units; and 

aggregating the guarantees of the data channels for the transaction 
stream. 
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1 2. (Original) The method as set forth in claim 1 1 , wherein 
aggregating comprises a function selected from the group consisting of summing 
the guarantees of the data channels of the transaction stream, selecting the 
maximum guarantees of the data channels of the transaction stream, and 
selecting the minimum guarantees of the data channels of the transaction 
stream. 

13. (Original) The method as set forth in claim 1 1 , wherein the 
guarantees are selected from the group consisting of quality of service 
guarantees, performance guarantees, bandwidth guarantees, latency 
guarantees, maximum outstanding request guarantees and maximum variance in 
service latency guarantees. 

14. (Previously Presented) A method for communicating data 
between functional blocks in a computing device, comprising: 

establishing at least one thread identifier, each thread identifier 
associating a data transfer with a transaction stream that the data transfer 
between an initiator functional block and a target functional block are part of; 

if the target functional block is unable to accept a data transfer from the 
initiator functional block, the target functional block issuing a busy signal 
identified by the thread identifier; 
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storing in a buffer data transfers received by the target functional block 
after issuance of the busy signal until resources become available to service the 
buffered data transfers, the amount of buffer sufficient to buffer any transfers that 
arrive after the busy signal is asserted, wherein an interface between the initiator 
functional block and target functional block does not block data transfers of other 
threads; and 

mapping a data flow from the initiator functional block to the target 
functional block to a thread indicated by the thread identifier to meet a service 
guarantee on a per thread identifier basis. 

15. (Original) The method as set forth in claim 14, wherein the 
target functional block issues a busy signal a determined number of clock cycles 
after the target functional block determines that it is unable to accept a data 
transfer from an initiator functional block. 

16. (Original) The method as set forth in claim 14, further 
comprising the target functional block receiving no more than a determined 
number of data transfers after issuance of the busy signal. 

17. (Original) The method as set forth in claim 14, further 
comprising determining service guarantees for at least one transaction stream 
between initiator functional blocks and the target functional blocks. 
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18. (Original) The method as set forth in claim 17, wherein 
determining service guarantees comprises: 

mapping the transaction stream to data channels of components between 
an initiator device and target device; 

converting performance guarantees of selected data channels of the 
mapped transaction stream such that the guarantees of the data channels are 
aligned to be uniform in units; and 

aggregating the guarantees of the data channels for the transaction 
stream. 

19. (Original) The method as set forth in claim 18, wherein 
aggregating comprises a function selected from the group consisting of summing 
the guarantees of the data channels of the transaction stream, selecting the 
maximum guarantees of the data channels of the transaction stream, and 
selecting the minimum guarantees of the data channels of the transaction 
stream. 

20. (Previously Presented) A communication apparatus, 
comprising: 

at least two functional blocks, wherein an initiator functional block 
communicates with a target functional block by establishing a connection; 

a bus coupled to each of the functional blocks and configured to carry a 
plurality of signals, wherein the plurality of signals comprises a thread identifier 
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configured to associate a data transfer with a transaction stream between the 
initiator functional block and target functional block, and a credit signal identified 
by the thread identifier, the credit signal issued by the target functional block to 
indicate how many data transfers the target functional block can accept, wherein 
the initiator functional block associated withholds issuance of data transfers 
associated with the thread identifier if the credit signal indicates that the target 
functional block can accept no data transfers, and the bus being non-blocking, 
via the use of credit signals, to enable a determination of service guarantees for 
transaction streams between initiator functional blocks and target functional 
blocks. 

21 . (Original) The apparatus as set forth in claim 20, wherein the 
busy signal comprises a signal that is maintained active when the target 
functional block is unable to accept data transfers. 

22. (Original) The apparatus as set forth in claim 20, wherein the 
busy signal comprises a credit signal comprising a number of credits that indicate 
how many data transfers the target functional block can accept. 

23. (Original) The apparatus as set forth in claim 22, wherein the 
number of credits is decremented for each active data transfer and incremented 
upon freeing up of resources for further data transfers. 
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24. (Original) The apparatus as set forth in claim 22, wherein the 
credit signal is generated by maintaining the signal in an active state for a 
number of clock cycles corresponding to the number of credits. 

25. (Previously Presented) The apparatus as set forth in claim 22, 
wherein the credit signal comprises a multi-bit coded signal indicative of the 
number of credits. 

26. (Original) The apparatus as set forth in claim 20, wherein the at 
least one transaction stream is non-blocking enabling determination of service 
guarantees for transaction streams between initiator functional blocks and target 
functional blocks. 

27. (Original) The apparatus as set forth in claim 20, wherein the 
target functional block further comprises a buffer to receive data transfers issued 
by the initiator functional block after issuance of the busy signal by the target 
functional block and before receipt of the busy signal by the initiator functional 
block. 

28. (Original) The apparatus as set forth in claim 27, wherein 
service guarantees are determined by mapping the transaction stream to data 
channels of components between an initiator device and target device, 
converting performance guarantees of selected data channels of the mapped 
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transaction stream such that the guarantees of the data channels are aligned to 
be uniform in units, and aggregating the guarantees of the data channels for the 
transaction stream. 

29. (Original) The apparatus as set forth in claim 28, wherein 
aggregating comprises a function selected from the group consisting of summing 
the guarantees of the data channels of the transaction stream, selecting the 
maximum guarantees of the data channels of the transaction stream, and 
selecting the minimum guarantees of the data channels of the transaction 
stream. 

30. (Original) The apparatus as set forth in claim 26, wherein the 
guarantees are selected from the group consisting of quality of service 
guarantees, performance guarantees, bandwidth guarantees, latency 
guarantees, maximum outstanding request guarantees and maximum variance in 
service latency guarantees. 

31 . (Previously Presented) A communication apparatus, 
comprising: 

at least two functional blocks, wherein an initiator functional block 
communicates with a target functional block by establishing a connection; 

a bus coupled to each of the functional blocks and configured to carry a 
plurality of signals, wherein the plurality of signals comprises at least one thread 
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identifier configured to associate a data transfer with a transaction stream that 
the data transfer between an initiator functional block and a target functional 
block are part of; wherein if the target functional block is unable to accept a data 
transfer from the initiator functional block, the target functional block issuing a 
busy signal identified by the thread identifier and buffering data transfers 
received after issuance of the busy signal until resources become available to 
service the buffered data transfers; 

a buffer coupled to the target functional block, the size of the buffer 
sufficient to buffer any number of data transfers that arrive on the transaction 
stream after the busy signal is asserted; and 

wherein the bus implements a mapping algorithm to map data flow of the 
transaction stream and aggregate service guarantees from components between 
the initiator functional block and the target functional block. 

32. (Original) The apparatus as set forth in claim 31 , wherein the 
target functional block issues a busy signal a determined number of clock cycles 
after the target functional block determines that it is unable to accept a data 
transfer from an initiator functional block. 

33. (Original) The apparatus as set forth in claim 31 , further 
comprising the target functional block receiving no more than a determined 
number of data transfers after issuance of the busy signal. 
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34. (Original) The apparatus as set forth in claim 31 , further 
comprising the target functional block determining service guarantees for at least 
one transaction stream between initiator functional blocks and the target 
functional blocks. 

35. (Original) The apparatus as set forth in claim 34, wherein 
determining service guarantees comprises: 

mapping the transaction stream to data channels of components between 
an initiator device and target device; 

selectively converting determine guarantees of data channels of 
components of the mapped transaction stream such that the guarantees of the 
data channels are aligned to be uniform in units; and 

aggregating the guarantees of the data channels for the transaction 
stream. 

36. (Original) The apparatus as set forth in claim 35, wherein aggregating 
comprises a function selected from the group consisting of summing the 
guarantees of the data channels of the transaction stream, selecting the 
maximum guarantees of the data channels of the transaction stream, and 
selecting the minimum guarantees of the data channels of the transaction 
stream. 
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X, EVIDENCE APPENDIX 



This Evidence Appendix includes the following documentation that was 
submitted during prosecution pursuant to 37 C.F.R. § 1 .31 : 

1 ) Telecom Glossary 2000, "Development Site for Proposed Revisions to 
American National Standard T1 .523-2001", 

http://www.its.bldrdoc.gov/proiects/devglossary/t1 q-main.html , 2000 (1 page). 

2) Definition of "Data Stream", 

http://www.its.bldrdoc.gov/proiects/devglossary/ data stream.html , June 6, 2005 
(1 page). 

3) Tech Encyclopedia: definition of "data stream", copyright 1981-2005, 

http://www.techweb.com/encyclopedia/defineterm. jhtml?term+data+stream&x~32 
&v=4 , (1 page). 

4) TechEncyclopedia: definition of "streaming data", copyright 1981-2005, 
http:www.techweb.com/encyclopedia/defineterm.jhtml?term=streaming+data f 
May 20, 2005 (1 page). 

5) Definition of "Thread", www,geek.com, prior to filing date of current 
application (1 page) 

6) Definition of "Thread", search VB.com Definitions-powered by whatis.com, 

http://searchvb.techtarget.com/sDefinition/0,290660,sid8 gci213139,00.html t 
May 20, 2005 (2 pages). 

7) internet.com (Webopedia), Definition of "thread", 
http://www.pcwebopaedia.com./TERM/t/thread.html , May 20, 2005 (2 pages). 

8) TechEncyclopedia, definition of "thread", copyright 1981-2005, 

http://www.techweb.com/encyclopedia/defineterm.ihtml?term=thread&x=16&y=1 
4, May 20, 2005 (1 page). 

9) TechEncyclopedia: definition of "multithreading", copyright 1981-2005, 

http://www.techweb.com/encyclopedia/defineterm. jhtml?term=multithreading f 
May 20, 2005 (1 page). 

10) internet.com (Webopedia), Definition of "multithreading", last modified 
October 24, 2002 (1 page). 
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1 1 ) http://www.faqs.org/faqs/threads-faq/part1/ , "comp.programming.threads 
FAQ [last mod 97/5/24]", May 24, 1997 (last modified date), pp. 1-18 (18 pages). 



12) OCP International Partnership, "Open Core Protocol Specification", 
Release 2.0, OCP-IP Confidential, Document Revision 1.1 .1, pp. 10, 19, 20 and 
46 (118 pages). 

1 3) PAWLAN, "Creating a Threaded Slide Show Applet", Sun Microsystems, 
Inc., The Source, 

http://iava.sun.com/developmer/technicalArticles/Threads/applet/ . March 16, 
2001, pp. 1-6 (6 pages). 
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XI. RELATED PROCEEDINGS APPENDIX 



There are no related proceedings and therefore no documentation to be 
included in this Related Proceedings Appendix. 
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Telecommunications Glossary 2000 



Page 1 of 1 



Development Site for proposed 

Revisions to 
American National Standard 

T1.523-2001 

This development site, while not yet fully functional, contains the baseline 
document Tl.523-2001, and allows you to propose revisions to this standard 
glossary. Just click on the "Add New or Comment" button below. 




revisions to American National Standard 

Telecom Glossary 2000 



To view the current, official version of ANS Tl.523-2001, Telecom Glossary 2000, go to 

website, 
http://ww w.atis.or g/tg2k / . 



Foreword: The communication of facts and ideas depends upon a mutual understanding 

of terminology. ... {FuUjext] 




V 

http://www.its.bldrd(x:.gov/projects/devg]ossary/tlg-main.html 6/9/2{X)5 



Definition: data stream ^ a § e 

data stream 



data stream: A sequence of digitally encoded signals used to represent information in 
transmission. 



This HTML version of Telecom Glossary 2K was last generated on Wed May 8 15:36:48 MDT 2002. 
Refe re nces can be found in the Foreword. 
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1) On the Internet in Usenet newsgroups and similar forums, a thread 
is a sequence of responses to an initial message posting. This 
enables you to follow or join an individual discussion in a newsgroup 
from among the many that may be there. A thread is usually shown 
graphically as an inital message and successive messages "hung off" 
the original message. As a newsgroup user, you contribute to a 
thread by specifying a "Reference" topic as part of your message. 

2) In computer programming, a thread is placeholder information 
associated with a single use of a program that can handle multiple 
concurrent users. From the program's point-of-view, a thread is the 
information needed to serve one individual user or a particular 
service request. If multiple users are using the program or concurrent 
requests from other programs occur, a thread is created and 
maintained for each of them. The thread allows a program to know 
which user is being served as the program alternately gets re-entered 
on behalf of different users. (One way thread information is kept by 
storing it in a special data area and putting the address of that data 
area in a register The operating system always saves the contents of 
the register when the program is interrupted and restores it when it 
gives the program control again.) 

A thread and a task are similar and are often confused. Most 
computers can only execute one program instruction at a time, but 
because they operate so fast, they appear to run many programs and 
serve many users simultaneously. The computer operating system 
gives each program a "turn" at running, then requires it to wait while 
another program gets a turn. Each of these programs is viewed by 
the operating system as a task for which certain resources are 
identified and kept track of. The operating system manages each 
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application program in your PC system (spreadsheet, word 
processor, Web browser) as a separate task and lets you look at and 
control items on a task list. If the program initiates an I/O request, 
such as reading a file or writing to a printer, it creates a thread. The 
data kept as part of a thread allows a program to be reentered at the 
right place when the I/O operation completes. Meanwhile, other 
concurrent uses of the program are maintained on other threads. 
Most of today's operating systems provide support for both 
multitasking and multithreading. They also allow multithreading within 
program processes so that the system is saved the overhead of 
creating a new process for each thread. 



The P0SIX.4a C specification provides a set of application program 
interfaces that allow a programmer to include thread support in the 
program. Higher-level program development tools and application 
subsystems and middleware also offer thread management facilities. 
Languages that support object-oriented programming also 
accommodate and encourage multithreading in several ways. Java 
supports multithreading by including synchronization modifiers in the 
language syntax, by providing class es developed for multithreading 
that can be inherited by other classes, and by doing background 
"garbage collection 11 (recovering data areas that are no longer being 
used) for multiple threads. 
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(1) In online 
discussions, a 
series of messages 
that have been 
posted as replies to 
each other. A single 
forum or 
conference 
typically contains 
many threads 
covering different 
subjects. By 

reading each message in a thread, one after the other, you can see 
how the discussion has evolved. You can start a new thread by 
posting a message that is not a reply to an earlier message. 

(2) In programming , a part of a program that can execute 
independently of other parts. Operating systems that support 
multithreading enable programmers to design programs whose 
threaded parts can execute concurrently. 
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multithreading 

The ability of an operating system to 
execute different parts of a program , 
called threads, simultaneously. The 
programmer must carefully design the 
program in such a way that all the 
threads can run at the same time without 
interfering with each other. 
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Introduction 



This posting consists of answers to many of the questions most 
frequently asked and summaries of the topics most frequently covere 
on comp. programming. threads, the Usenet newsgroup for discussion of 
issues in multithreaded programming. The purpose of this posting is 
circulate existing information, and to avoid rehashing old topics o 
discussion and questions. Please read all parts of this document 
before posting to this newsgroup. 

The FAQ is posted monthly to comp. programming . threads , in multiple 
parts. It is also available on the World-Wide Web, at 
<URL: http : / /www . serpentine . com/~bos/ threads-f aq > . You may prefer t 
browse the FAQ on the Web rather than on Usenet, as it contains man 
useful hyperlinks (and tables are readable, which is unfortunately 
the case for the text version) . 
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2.1. Reader contributions and comments 

Your contributions, comments, and corrections are welcomed; mail se 
to <threads-f aq@serpentine . com> will be dealt with as quickly as I 
manage. Generally, performing a reply or followup to this article f 
within your newsreader should do the Right Thing. 

While I am more than happy to include submissions of material for t 
FAQ if they seem appropriate, it would make my life a lot easier if 
such text were proof-read in advance, and kept concise. I don't hav 
as much time as I would like to digest 15K text files and summarise 
them in three paragraphs for inclusion here. If you are interested 
contributing material, please see the to-do list at the end of part 
of the FAQ. 

2.2. How to read this FAQ 

Some headers in this FAQ are preceded by words in parentheses, such 
" (POSIX) " . This indicates that the sections in question are specif i 
to a particular threads family, or to the implementation provided b 
specific vendor. 

Wherever it may not otherwise be obvious that a particular section 
refers only to some families or implementations, you will find one 
more of the following key words to help you. 
Key Implementation 

DCE OSF/DCE threads (POSIX draft 4) 
OS/2 IBM OS/2 threads 

POSIX POSIX 1003.1c-1995 standard threads 
UI Unix International threads 
Unix Of general relevance to Unix users 
WIN32 Microsoft Win32 API threads 

2.3. Acknowledgments and caveats 

Although this FAQ has been the result of a co-operative effort, any 

blame for inaccuracies and/or errors lies entirely with my work. I 

would like to thank the following people for their part in 

contributing to this FAQ: 

Dave Butenhof < butenhof @zko . dec . com > 

Bil Lewis <bil@lambdaCS . com> 



3. What are threads? 

A thread is an encapsulation of the flow of control in a program. M 
people are used to writing single- threaded programs - that is, 
programs that only execute one path through their code "at a time". 
Multithreaded programs may have several threads running through 
different code paths "simultaneously". 
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Why are some phrases above in quotes? In a typical process in which 
multiple threads exist, zero or more threads may actually be runnin 
at any one time. This depends on the number of CPUs the computer on 
which the process is running, and also on how the threads system is 
implemented. A machine with _n_ CPUs can, intuitively enough, run n 
more than _n_ threads in parallel, but it may give the appearance o 
running many more than _n„ "simultaneously n , by sharing the CPUs am 
threads . 

3.1. Why are threads interesting? 

A context switch between two threads in a single process is 
_considerably_ cheaper than a context switch between two processes, 
addition, the fact that all data except for stack and registers ar<e 
shared between threads makes them a natural vehicle for expressing 
tasks that can be broken down into subtasks that can be run 
cooperatively . 

3.2. A little history 

If you are interested in reading about the history of threads, see 
relevant section of the comp . os . research FAQ at 
<URL : http: / /www. serpentine . com/-bos/os-f aq > . 

4. What are the main families of threads? 

There are two main families of threads: 

* POSIX-style threads, which generally run on Unix systems. 

* Microsoft-style threads, which generally run on PCs. 

These families can be further subdivided. 
4.1. POSIX-style threads 

This family consists of three subgroups: 

* "Real" POSIX threads, based on the IEEE POSIX 1003.1c-1995 (als 
known as the ISO/IEC 9945-1:1996) standard, part of the ANSI/IE 
1003.1, 1996 edition, standard. POSIX implementations are, not 
surprisingly, the emerging standard on Unix systems. 

+ POSIX threads are usually referred to as Pthreads . 

+ You will often see POSIX threads referred to as POSIX. lc 

threads, since 1003.1c is the section of the POSIX standar 

that deals with threads. 
+ You may also see references to draft 10 of POSIX. lc, which 

became the standard. 

* DCE threads are based on draft 4 (an early draft) of the POSIX 
threads standard (which was originally named 1003.4a, and becam 
1003.1c upon standardisation). You may find these on some Unix 
implementations . 

* Unix International (UI) threads, also known as Solaris threads, 
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are based on the Unix International threads standard (a close 
relative of the POSIX standard) . The only major Unix variants t 
support UI threads are Solaris 2, from Sun, and UnixWare 2, fro 
SCO . 

Both DCE and UI threads are fairly compatible with the POSIX thread 
standard, although converting from either to "real" POSIX threads w 
require a moderate amount of work. 

Those few tardy Unix vendors who do not. yet ship POSIX threads 
implementations are expected to do so "real soon now" . If you are 
developing multithreaded applications from scratch on Unix, you wou 
do well to use POSIX threads. 

4.2. Microsoft-style threads 

This family consists of two subgroups, both originally developed by 
Microsoft . 

* WIN32 threads are the standard threads on Microsoft -Windows 95 
Windows NT. 

* OS/2 threads are the standard threads on OS/2, from IBM. 

Although both of these were originally implemented by Microsoft, th 
have diverged somewhat over the years. Moving from one to the other 
will require a moderate amount of work. 

4.3. Others 

Mach and its derivatives (such as Digital UNIX) provide a threads 
package called C threads. This is not very widely used. 

5 . Some terminology 

The terms here refer to each other in a myriad of ways, so the best 
way to navigate through this section is to read it, and then read i 
again. Don't be afraid to skip forwards or backwards as the need 
appears . 

5.1. (DCE, POSIX, UI) Async safety 

Some library routines can be safely called from within signal 
handlers; these are referred to as async-safe. A thread that is 
executing some async-safe code will not deadlock if it is interrupt 
by a signal. If you want to make some of your own code async-safe, 
should block signals before you obtain any locks. 

5.2. Asynchronous and blocking system calls 

Most system calls, whether on Unix or other platforms, block (or 
"suspend") the calling thread until they complete, and continue its 
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execution immediately following the call. Some systems also provide 
asynchronous (or _non-hlocking_) forms of these calls; the kernel 
notifies the caller through some kind of out-of-band method when su 
a system call has completed. 

Asynchronous system calls are generally much harder for the program 
to deal with than blocking calls. 

5.3. Context switch 

A context switch is the action of switching a CPU between executing 
one thread and another (or transferring control between them) . This 
may involve crossing one or more protection boundary. 

5.4. Critical section 

A critical section of code is one in which data that may be accesse 
by other threads are inconsistent. At a higher level, a critical 
section can be viewed as a section of code in which a guarantee you 
make to other threads about the state of some data may not be true. 

If other threads can access these data during a critical section, y 
program may not behave correctly. This may cause it to crash, lock 
produce incorrect results, or do just about any other unpleasant th 
you care to imagine. 

Other threads are generally denied access to inconsistent data duri 
a critical section (usually through use of locks) . If some of your 
critical sections are too long, however, it may result in your code 
performing poorly. 

5.5. Lightweight process 

A lightweight process (also known in some implementations, 
confusingly, as a ^kernel thread_) is a schedulable entity that the 
kernel is aware of. On most systems, it consists of some execution 
context and some accounting information (i.e. much less than a 
full-blown process) . 

Several operating systems allow lightweight processes to be "bound" 
particular CPUs; this guarantees that those threads will only execu 
on the specified CPUs. 

5.6. MT safety 

If some piece of code is described as MT-safe, this indicates that 
can be used safely within a multithreaded program, _and_ that it 

supports a "reasonable" level of concurrency. This isn't very 

interesting; what you, as a programmer using threads, need to worry 
about is code that is _not_ MT-safe. MT-unsafe code may use global 
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and/or static data. If you need to call MT-unsafe code from within 
multithreaded program, you may need to go to some effort to ensure 
that only one thread calls that code at any time. 

Wrapping a global lock around MT-unsafe code will generally let you 
call it from within a multithreaded program, but since this does no 
permit concurrent access to that code, it is not considered to make 
MT-safe. 

If you are trying to write MT-safe code using POSIX threads, you ne 
to worry about a few issues such as dealing correctly with locks 
across calls to fork (2) (if you are wondering what to do, read abou 
the pthread_atf ork (3 ) library call). 

5.7. Protection boundary 

A protection boundary protects one software subsystem on a computer 
from another, in such a way that only data that is explicitly share 
across such a boundary is accessible to the entities on both sides, 
general, all code within a protection boundary will have access to 
data within that boundary. 

The canonical example of a protection boundary on most modern syste 
is that between processes and the kernel. The kernel is protected f 
processes, so that they can only examine or change its internal sta 
in certain strictly-defined ways. 

Protection boundaries also exist between individual processes on mo 
modern systems. This prevents one buggy or malicious process from 
wreaking havoc on others. 

Why are protection boundaries interesting? Because transferring 
control across them is expensive; it takes a lot of time and work. 

5.8. Scheduling 

Scheduling involves deciding what thread should execute next on a 
particular CPU. It is usually also taken as involving the context 
switch to that thread. 

6. What are the different kinds of threads? 

There are two main kinds of threads implementations; 

* User-space threads, and 

* Kernel-supported threads. 

There are several sets of differences between these different threa 
implementations . 

6.1. Architectural differences 
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User-space threads live without any support from the kernel; they 
maintain all of their state in user space. Since the kernel does no 
know about them, they cannot be scheduled to run on multiple 
processors in parallel. 

Kernel-supported threads fall into two classes. 

* In a "pure" kernel -supported system, the kernel is responsible 
scheduling all threads. 

* Systems in which the kernel cooperates with a user-level librar 
to do scheduling are known as _two-level_, or _hybrid_, systems 
Typically, the kernel schedules LWPs, and the user-level librar 
schedules threads onto LWPs. 

Because of its performance problems (caused by the need to cross th 
user/kernel protection boundary twice for _every__ thread context 
switch) , the former class has fewer members than does the latter (a 
least on Unix variants) . Both classes allow threads to be run acros 
multiple processors in parallel. 

6.2. Performance differences 

In terms of context switch time, user-space threads are the fastest 
with two-level threads coming next (all other things being equal) . 
However, if you have a multiprocessor, user-level threads can only 
run on a single CPU, while both two-level and pure kernel -supported 
threads can be run on multiple CPUs simultaneously. 

6.3. Potential problems with functionality 

Because the kernel does not know about user threads, there is a dan 
that ordinary blocking system calls will block the entire process 
(this is _bad_) rather than just the calling thread. This means tha 
user-space threads libraries need to jump through hoops in order to 
provide "blocking" system calls that don't block the entire process 

This problem also exists with two- level kernel-supported threads, 
though it is not as acute as for user-level threads. What usually 
happens here is that system calls block entire LWPs. This means tha 
if more threads exist than do LWPs and all of the LWPs are blocked 
system calls, then other threads that could potentially make forwar 
progress are prevented from doing so. 

The Solaris threads library provides a reasonable solution to this 
problem. If the kernel notices that all LWPs in a process are block 
it sends a signal to the process. This signal is caught by the 
user- level threads library, which can create another LWP so that th 
process will continue to make progress. 

7. Where can I find books on threads? 
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There are several books available on programming with threads, with 
more due out in the near future. Note also that the programmer's 
manuals that come with most systems that provide threads packages w 
have sections on using those threads packages. 

7.1. POSIX-style threads 

David R. Butenhof, ^Programming with POSIX Threads_. Addison-Wesley 
ISBN 0-201-63392-2. 

This book gives a comprehensive and well-structured overview 
programming with POSIX threads, and is a good text for the 
working programming to work from. Detailed examples and 
discussions abound . 

Steve Kleiman, Devang Shah and Bart Smaalders, ^Programming With 
Threads.. SunSoft Press, ISBN 0-13-172389-8. 

<URL: http: //www. sun . com/ smi /ssof tpr ess /books /Kleiman/Kleima 
tml> 

This book goes into considerably greater depth than the othe 
SunSoft Press offering (see below) , and is also recommended 
the working programmer who expects to deal with threads on a 
day-to-day basis. It includes many detailed examples. 

Bil Lewis and Daniel J. Berg, _Threads Primer_. SunSoft Press, 
ISBN 0-13-443698-9. 

<URL : http: //www. sun . com/ smi/ ssof tpr ess /books /Lewis /Lewis .ht 

This is a good introduction to programming with threads for 
programmers and managers. It concentrates on UI and POSIX 
threads, but also covers use of OS/2 and WIN32 threads. 

Charles J. Northrup, ^Programming With Unix Threads^. John Wiley & 
Sons, ISBN 0-471-13751-0. 

<URL: http: / /www. wi ley . com/ compbooks /catalog / 14 / 13 7 51-0 . html 
This book details the UI threads interface, focusing mostly 
the UnixWare implementation. This is an introductory book. 

7.2. Microsoft-style threads 

Jim Beveridge, Robert Wiener, _Multithreading Applications in Win32 
Addison-Wesley, ISBN 0-201-44234-5. 

<URL: http: / /www. aw . com/devpress / titles/ 44234 ,html > . 
Seasoned Win32 programmers, neophytes, and programmers being 
dragged kicking and screaming from the Unix world are all 
likely to find this book a useful resource. It doubles as 
primer and reference on writing and debugging robust 
multithreaded code, and provides a thorough exposition on th 
subj ect . 
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Len Dorfman, Marc J. Neuberger, .Effective Multithreading with OS/2- 
Publisher and ISBN unknown. 

This book covers the OS/2 threads API and contains many 
examples, but doesn't have much by way of concepts. 

Thuan Q. Pham, Pankaj K . Garg, .Multithreaded Programming with 
Windows NT_. Prentice Hall, ISBN 0-131-20643-5. 
<URL: http: / /www . prenhall . com/ 013 / 12 0642 / 12 064 -2 . html> 
Not surprisingly, this book focuses on WIN32 threads, but it 
also mentions other libraries in passing. It also deals with 
some relatively advanced topics, and has a thorough 
bibliography. 

7.3. Books on implementations 

If you are interested in how modern operating systems support threa 
and multiprocessors, there are a few excellent books available that 
may be of interest to you. 

Curt Schimmel, _Unix Systems for Modern Architectures.. 
Addison-Wesley, ISBN 0-201-63338-8. 
<URL: http: / /www . aw . com/cp/ schimmel .html > 

This book gives a lucid account of the work needed to .get Un 
(or, for that matter, more or less anything else) working on 
modern system that incorporates multiple processors, each wi 
its own cache. While it has some overlap with the Vahalia bo 
(see below) , it has a smaller scope, and thus deals with sha 
topics in more detail. 

Uresh Vahalia, .Unix Internals: the New Frontiers.. Prentice Hall, 
ISBN 0-13-101908-2. 

<URL: http: //www. prenhall .com/013/101907/10190-7 .html> 
This is the best kernel internals book currently available, 
deals extensively with building multithreaded kernels, 
implementing LWPs, and scheduling on multiprocessors. Given 
choice, I would buy .both, this and the Schimmel book. 

Ben Catanzaro, ..Multiprocessor System Architectures.. SunSoft Press 
ISBN 0-13-089137-1. 

<URL: http: / /www . sun . com/ smi /ssof tpr ess /books /Catanzaro/Cata 
ro . html> 

I don't know much about this book, but it deals with both th 
hardware and software (kernel and user) architectures used t 
put together modern multiprocessor systems. 

7.4. The POSIX threads standard 

To order ISO/IEC standard 9945-1:1996, which is also known as 

ANSI /IEEE POSIX 1003.1-1995 (and includes 1003.1c, the part that de 

with threads), you can call +1-908-981-1393. The document reference 
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number in the IEEE publications catalogue is SH 943S2-NYF, and the 
price to US customers is $120 (shipping overseas costs extra) . 

Unless you are implementing a POSIX threads package, you should not 
ever need to look at the POSIX threads standard. It is the last pla 
you should look if you wish to learn about threads! 

Neither IEEE nor ISO makes standards available for free; please do 
ask whether the POSIX threads standard is available on the Web. It 
isn ' t . 

'8. Where can I obtain training on using threads? 

Organisation Contact Description 
Sun Microsystems < training_seats@Sun . COM > 
+1-408-276-3630 Classes at Sun and on-site classes 
Lambda Computer Science 

(Bil Lewis) <URL: http: // www . lambda CS . com > 
+1-415-328-8952 Seminars and on-site classes 
Phoenix Technologies 

(Chris Crenshaw) <phnxtech@att mail . com> 
+1-908-286-2118 

Marc Staveley < marc@staveley . com > 
9. (Unix) Are there any freely-available threads packages? 

* Xavier Leroy <xleroy@inria . f r> has written a POSIX threads 
implementation for Linux 2.x that uses pure kernel -supported 
threads. While the package is currently in alpha testing, it is 
allegedly very stable. For more information, see 

<URL : http: //pauillac . inria . f r /-xleroy /linuxthreads > . 

* Michael T. Peterson < mtp@big . aa . net > has written a user- space 
POSIX and DCE threads package for Intel -based Linux systems; it 
called PCthreads. See <URL: ht tp : / /www . aa . net / -mtp / PC threads . ht 
for more information. 

* Christopher Provenzano <prove n@mit . ed u> has written a fairly 
portable implementation of draft 8 of the POSIX threads standar 
See <URL: http: //www. mi t .edu: 8001/people/proven/pthreads ,html> 
further details. _Note_: as far as I can see, development of th 
library has halted (at least temporarily), and it still -contain 
many serious bugs. 

* Georgia Tech's OS group has a fairly portable user-level thread 
implementation of the Mach C threads package. It is called 
Cthreads, and can be found at 

<URL : ftp://ftp.cc. gatech . edu/pub/groups /systems /Falcon/ 
istribution. tar .gz> . 

* Frank Miiller, of the POSIX / Ada -Runtime Project (PART) has mad 
available an implementation of draft 6 of the POSIX 1003.4a 
Pthreads specification, which runs under SunOS 4, Solaris 2.x, 
SCO Unix, FreeBSD and Linux. For more information, see 
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<URL: file: / /ftp, cs.fsu. edu /pub/ PART/ PTHREADS /pthr eads_ANNOUNCE 

* Elan Feingold has written a threads package called ethreads-; I 
don't know anything about it, other than that it is available f 
<URL: ftp: lit rmap711 .mathp7 . jussieu. f r /pub/scratch/rideau/misc/ 
eads/ethreads/ethreads . tgz> . 

* QuickThreads is a toolkit for building threads packages, writte 
by David Keppel < pardo@cs .Washington . edu > . It is available from 
<URL: ftp://ftp.es . wa shinq t on . edu /pub/qt - 001 . tar . Z >, with an 
accompanying tech report at 

<URL: ftp: / /ftp . cs .Washington . edu/tr/ 1993 / 05 /UW-CSE-93 -05- 06 . PS 
. The code as distributed includes ports for the Alpha, x86, 
88000, MIPS, SPARC, VAX , and KSR1 . 

10. (DCE , POSIX, UI) Why does my threaded program not handle signals 

Signals and threads do not mix well. A lot of programmers start out 
writing their code under the mistaken assumption that they can set 
signal handler for each thread; this is not the way things work. Yo 
can _block_ or _unblock_ signals on a thread-by- thread basis, but t 
is not the same thing. 

When it comes to dealing with signals, the best thing you can do is 
create a thread whose sole purpose is to handle signals for the ent 
process. This thread should loop calling sigwait(2); this allows it 
deal with signals synchronously. You should also make sure that all 
threads (_including_ the one that calls sigwait) have the signals y 
are interested in handling blocked. Handling signals synchronously 
this way greatly simplifies things. 

Note, also, that sending signals to other threads within your own 
process is not a friendly thing to do, unless you are careful with 
signal masks. For an explanation, see the section on asynchronous 
cancellation. 

Finally, using sigwait and installing signals handlers for the sign 
you are sigwaiting for is a bad idea. 

11. (DCE?, POSIX) Why does everyone tell me to avoid asynchronous ca 

Asynchronous cancellation of threads is, in general, evil. The reas 
for this is that it is usually (very) difficult to guarantee that t 
recipient of an asynchronous cancellation request will not be in a 
critical section. If a thread should die in the middle of a critica 
section, this will very likely cause your program to misbehave. 

Code that can deal sensibly with asynchronous cancellation requests 
_not_ referred to as async-safe; that means something else (see the 
terminology section of the FAQ) . You won't see much code around tha 
handles asynchronous cancellation requests properly, and you should 
try write any of your own unless you have compelling reasons to do 
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Deferred cancellation is your friend. 

12. Why are reentrant library and system call interfaces good? 

There are two approaches to providing system calls and library 
interfaces that will work with multithreaded programs. One is to 
simply wrap all the appropriate code with mutexes, thereby 
guaranteeing that only one thread will execute any such routine at 
time . 

While this approach mostly works, it provides terrible performance. 
For functions that maintain state across multiple invocations 
(e.g. strtokO and friends), this approach simply doesn't work at a 
hence the existence of '^r" interfaces on many Unix systems (see 
below) . 

A better solution is to ensure that library calls can safely be 
performed by multiple threads at once. 

12.1. (DCE, POSIX, UI) When should I use thread-safe "_r" library call 

If your system provides threads, it will probably provide a set of 
thread-safe variants of standard C library routines. A small number 
these are mandated by the POSIX standard, and many Unix vendors 
provide their own useful supersets, including functions such as 
gethostbyname_r ( ) . 

Unfortunately, the supersets that different vendors support do not 
necessarily overlap, so you can only _safely_ use the standard 
POSIX-mandated functions. The thread-safe routines are conceptually 
"cleaner" than their stateful counterparts, though, so it is good 
practice to use them wherever and whenever you can. 

13. (POSIX) How can I perform a join on any thread? 

UI threads allow programmers to join on any thread that happens to 
terminate by passing the appropriate argument to thr^_join(). This i 
not possible under POSIX and, yes, there is a rationale behind the 
absence of this feature. 

Unix programmers are used to being able to call wait() in such a wa 
that it will return when "any M process exits, but expecting this to 
work for threads can cause confusion for programmers trying to use 
threads. The important thing to note here is that Unix processes ar 
based around a notion of parent and child; this is a notion that is 
_not_ present in most threads systems. Since threads don't contain 
this notion, joining on "any" thread could have the undesirable eff 

of having the join return once a completely unrelated thread happen 
to exit. 
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In many (perhaps even most) threaded applications, you do not want 
be able to join with any thread in your process. Consider, for 
example, a library call that one of your threads might make, which 
its turn might start a few threads and try to join on them. If anot 
of your threads, joining on "any" thread, happened to join on one o 
the library call's threads, that would lead to incorrect program 
behaviour . 

If you want to be able to join on any thread so that, for example, 
can keep track of the number of running threads, you can achieve th 
same functionality by starting detached threads and having them 
decrememnt a (suitably locked, of course) counter as they exit. 

14. (DCE , UI, POSIX) After I create a certain number of threads, my 

crashes 

Ey default, threads are created non-detached. You need to perform a 
join on each non-detached thread, or else storage will never be fre 
up when they exit. As an alternative, you can create detached threa 
for which storage will be freed as soon as they exit. This latter 
approach is generally better; you shouldn't create non-detached 
threads unless you explicitly need to know when or if they exit. 

15. Where can I find POSIX thread benchmarks? 
I do not know of any benchmarks. 

16. Does any DBMS vendor provide a thread-safe interface? 

Oracle 7.3 and above provide thread-safe database client interfaces 
as do Sybase System 11.1 and above, and Informix ESQL 7 and above. 

If you are still using an older release of any of these products, i 
is possible to hack together a set of intermediate thread-safe 
interfaces to your database if you really need it, but this require 
moderately large amount of work. 

17. Why is my threaded program running into performance problems? 

There are many possible causes for performance problems in 
multithreaded programs. Given the scope for error, all I can do is 
detail a few common pitfalls briefly, and point you at the section 
this FAQ on books about multithreaded programming. 

* You can probably discount the performance of the threads packag 
you are using almost straight away, unless it is a user-level 
package. If so, you may want to try to find out whether your wh 
process is blocking when you execute certain system calls. 
Otherwise, you should look at your own code unless you have a v 
strong reason for believing that there may be a problem with yo 
threads package . 
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* Look at the granularity of your locks. If a single lock protect 
too much data for which there is contention, you will needlessl 
serialise your code. On the other hand, if your locks protect v 
small amounts of data, you will spend too much time obtaining a 
releasing locks. If your vendor is worth their salt, they will 
have a set of tools available that allow you to profile your 
program's behaviour and look for areas of high contention for 
locks. Tools of this kind are invaluable. 

18. What tools will help me to program with threads? 

* The TNF Tools are a set of extensible tools that allow users to 
gather and analyse trace information from the Solaris kernel an 
from user processes and threads. They can be used to correlate 
user and kernel thread activity, and also to determine such thi 
as lock hold times. They are available for free from Sun; for m 
information, see 

<URL : h t tp : I / gpcom L .su_n^^t_oplpaqes/tnf tools . html > . 

* The debugger that comes with the DevPro compiler set from Sun 
understands threads . 

* GDB nominally understands threads, but only supports them (and 
a flaky way) under some versions of Irix and a few other system 
(mostly embedded machines) . 

19. What operating systems provide threads? 

Vendor OS version Threads model POSIX API Notes 
Digital Digital UNIX 4.0 mixed D4 , lc 
Digital UNIX 3.2 kernel / bound D4 

OpenVMS 7.0 (Alpha) see note 1 D4 , lc user model without patch kit 
OpenVMS 7.0 (VAX) user D4 , lc 
OpenVMS 6.2 user D4 

HP HP/UX 10.20 _?_ not yet announced 

HP/UX 10.10 user D4 

IBM AIX 4.1 & 4.2 kernel D4, D7 

AIX 3.5.x user DCE 

OS/2 kernel DCE 

Linux Linux 1.2.13 and above user / kernel lc, DCE see free 
implementations for several packages 
Linux 2.x kernel _n/a_ clone () interface 

Microsoft Windows NT & 95 kernel DCE DCE kits layer on top of WIN32 
threads 

SGI Irix 6.2 mixed see note 2 sproc ( ) is still kernel / bound 
Irix 6.1 kernel / bound _n/a_ sproc ( ) interface only 
Sun Solaris 2.5 and above mixed / system / bound lc 

Solaris 2.4 mixed / system / bound D8 available from Sun only upon 
request 

Solaris 2.x mixed / system / bound _n/a_ UI threads supported acros 
all releases 

SunOS 4.x user _n/a_ LWP only 



hUp://www.faqs.org/faqs/threads-faq/partl/ 



5/20/2005 



comp.programming.threads FAQ [last mod 97/5/24] 



Page 16 of 18 



Threads model Meaning 
user 

a purely user-level threads system, with threads multiplexed atop a 

•'traditional" Unix-style process 

kernel 

threads are "kernel entities" with no context switches taking place 
user mode 

/ bound a thread may be explicitly bound to a particular processor 
mixed 

a mixed-mode scheduler where user threads are multiplexed across so 
number of LWPs 

/ system threads have "system" contention scope (a user thread may 
permanently bound to an LWP) 

/ bound an LWP may be permanently bound to a particular processor 
API Weaning 

_n/a_ no POSIX threads API provided 

lc conforms to the POSIX 1003.1c-1995 threads API 

DCE POSIX 1003.4a draft 4 API is available as part of the OSF DCE k 
for the platform 

D4 DCE threads (or something similar) is bundled with the system 
D7 POSIX 1003.4a draft 7 API (similar to the final 1003.1c standard 
but substantially different in some details) 

D8 POSIX 1003.4a draft 8 API (identical in most respects to the 
1003.1c standard, but with a few "gotchas" ) 

1. OpenVMS 7.0 for Alpha shipped with kernel threads support disabl 

by default. The "mixed" threads model can be turned on by setti 
the MULTI THREAD sysgen parameter. With patch kit, the "mixed" o 
"user" model is determined by the main program binary (i.e. via 
the linker or the threadcp qualifier) in addition to MULTI THREA 

2. SGI ships the POSIX 1003.1c API as a patch for Irix 6.2, but it 

will be bundled with future revisions of the OS. 

20. What about other threads-related software? 

* Douglas C. Schmidt < schmidt@cs .wustl .edu > has written a package 
called ACE (.Adaptive Communication Environment.) . ACE supports 
multithreading on Unix and WIN32 platforms, and integrates popu 
IPC mechanisms (sockets, RPC, System V IPC) and a host of other 
features that C++ programmers will find useful. For details, se 
<URL: http: / /www . cs . wust 1 . edu/~schmidt /ACE . html > . 

21. Where can I find other information on threads? 

* The most comprehensive collection of threads-related informatio 
on the Web is at Sun 1 s threads page, at 

<URL: http: //www. sun. com/ sunsoft/ Products/Developer -products /si 
hreads> . 
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* IBM has a thorough treatment of AIX 4.1 threads (based on POSIX 
draft 7) at 

<URL : http : / /developer . aust in . ibjn . c om/sdp/librarv/ref /about 4 . 1 / 
threa .html> . 

* Digital has a brief overview of threads in Digital UNIX at 
<URL : http: / /www . unix . digital . co m/ unix/smp > . 

* A bibliography on threads is available at 

< URL : http: / / 1 i inwww. i ra . uk a ^_d ej bi bl iography/Os/ threads . html > . 

* Tom Wagner < wagner@cs . umass . ed u> and Don Towsley have written a 
introductory tutorial on programming with POSIX threads at 
<URL : http: / /centaurus . cs .umass . edu/~wagner / threads_html / tutori 
html> 

21.1. Articles appearing in periodicals 

* An introduction to programming with threads, at 

<URL : http : / /www. sun . com/ sunwor Idonline/swol -02 -1996 /swol - 02 - th 
ds.html>, from SunWorld Online' s February 1996 issue 

* An introduction to programming with threads, at 

<URL : http: //developer .austin . ibm . com/ sdp/ library /aixpert /nov94 
xpert_nov94_intrmult .html> , from AlXpert Magazine's November 19 
issue 

* Porting DCE threads to AIX 4.1 (POSIX draft 7), at 

< URL : ht^:j^/v^ com / s dp / 1 ib r ary / aixpert / aug 9 4 / a i 

rt_aug94_PTHREADS . html> , from AlXpert Magazine's August 1994 is 

* A less thorough introduction to programming with threads, at 

< URL : ht t p :J ../ dj^yje ^ .ibm .com/ sdp / 1 ibr a ry / a i xper t / aug 95 

xpert_aug95_thread.html>, from AlXpert Magazine's August 1995 
issue 

* Using signals with POSIX threads, at 

<URL : http : / /developer . austin . ibm . com/ sdp/ library /aixpert /aug9 5 
xpert_aug95_signal .html>, from AlXpert Magazine's August 1995 
issue 

22. Notice of copyright and permissions 

Answers to Frequently Asked Questions for comp .programming . threads 
(hereafter referred to as These Articles) are Copyright © 1996 and 
1997 by Bryan O'Sullivan (hereafter referred to as The Author). 

These Documents are provided "as is". The information in them is no 
warranted to be correct; you use it at your own risk. The Author ma 
_no representation or warranty., as to the suitability of the 
information in These Documents, either express or implied, includin 
but not limited to the implied warranties of fitness for a particul 
purpose or non-infringement. The Author shall not be liable for any 
damages suffered as a result of using information distributed in Th 
Documents or any derivatives. 

These Documents may be reproduced and distributed in whole or in pa 
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subject to the following conditions: 

* This copyright , and permission notice must be retained on all 
complete or partial copies of These Articles. 

* These Articles may be copied or distributed in part or in full 
personal or educational use. Any translation, derivative work, 
copies made for other purposes must be approved by the copyrigh 
holder before distribution, unless otherwise stated. 

* If you distribute These Articles, instructions for obtaining th 
complete current versions of them free or at cost price must be 
included. Redistributors must make reasonable efforts to mainta 
current copies of These Articles. 

Exceptions to these rules may be granted, and I shall be happy to 
answer any questions about this copyright notice - write to Bryan 
0' Sullivan, PO Box 62215, Sunnyvale, CA 94088-2215, USA or email 
< bos@ serpen tine . com > . These restrictions are here to protect the 
contributors, not to restrict you as educators, professionals and 
learners . 



Rate this FAQ 



N/A 




Related que st ions and answers 



f Usenet FAQs I Search I Web FAQs I Documents I RFC Index 1 



Send corrections/additions to the FAQ Maintainer: 
threads-faq@serpentine.com 
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Introduction 



The Open Core Protocol™ (OCP™) delivers the only non-proprietary, openly 
licensed, core-centric protocol that comprehensively describes the system- 
level Integration requirements of intellectual property (IP) cores. 

While other bus and component interfaces address only the data flow aspects 
of core communications, the OCP unifies all Inter-core communications, 
including sideband control and test harness signals. The OCPs synchronous 
unidirectional signaling produces simplified core Implementation, integra- 
tion, and timing analysis. 

OCP eliminates the task of repeatedly defining, verifying, documenting and 
supporting proprietary Interface protocols. The OCP readily adapts to support 
new core capabilities while limiting test suite modifications for core upgrades. 

Clearly delineated design boundaries enable cores to be designed indepen- 
dently of other system cores yielding definitive, reusable IP cores with 
reusable verification and test suites. 

Any on-chip Interconnect can be interfaced to the OCP rendering it appro- 
priate for many forms of on-chip communications: 

• Dedicated peer-to-peer communications, as In many pipelined signal 
processing applications such as MPEG2 decoding. 

• Simple slave-only applications such as slow peripheral interfaces. 

• High-performance, latency-sensitive, multi-threaded applications, such 
as multi-bank DRAM architectures. 

The OCP supports very high performance data transfer models ranging from 
simple request-grants through pipelined and multi-threaded objects. Higher 
complexity SOC communication models are supported using thread identi- 
fiers to manage out-of-order completion of multiple concurrent transfer 
sequences. 
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The CoreCreator™ tool automates the tasks of building, simulating, verifying 
and packaging OCP-compatible cores* IP core products can be fully "compo- 
nentized" by consolidating core models, timing parameters, synthesis scripts, 
verification suites and test vectors in accordance with the OCP Specification. 
CoreCreator does not constrain the user to either a specific methodology or 
design tool. 



Support 

The OCP Specification is maintained by the Open Core Protocol International 
Partnership (OCP-IP™), a trade organization solely dedicated to OCP, 
supporting products and services. For all technical support Inquiries, please 
contact techsupport@ocpIp.org. For any other information or comments, 
please contact admin@ocplp.org. 



Changes for Revision 2.0 of the Specification 

This 2.0 revision of the OCP Specification is an evolution of the 1.0 version. 
New features were defined by the Specification Working Group of OCP-IP. The 
major changes and new additions are: 

• Variations of the write posting model. This includes writes with responses 
(writeresp_enable) and the new command WriteNfonPosL 

• A new burst model that emphasizes precise bursts and bursts that have 
a single request with multiple data word transfers. The revision 2.0 burst 
model is a functional superset of the version 1.0 burst model, and 
replaces that burst model completely. 

• To increase the flexibility of single request / multiple data bursts, support 
for separate write byte enables (MDataByteEnable) and a threadbusy 
signal for the datahandshake phase (SDataThreadBusy). 

• Subsets of the OCP Interface are now allowed that, for example enable 
read-only or write-only interfaces. 

• In-band extensions that allow the master and slave to communicate core- 
specific in-band information (such as cacheable Information or parity) 
with each protocol phase. 

• An explicit specification of endianness. While each OCP Interface by Itself 
Is endian neutral, endianness matters when communicating between 
cores of different data widths in a system. 

• The lazy (non-blocking) synchronization pair ReadLInked/ 
WriteConditlonal was added to the existing blocking synchronization pair 
ReadEx/Write or WriteNonPost, to support processors that natively make 
use of lazy synchronization. 

• A set of protocol parameters that optionally tightens the semantics of 
SThreadBusy and MThreadBusy, in order to guarantee that multi- 
threaded OCP interfaces be non-blocking. 

OCP-IP Confidential 



XV 



• Reset Is extended to enable dual resets, one driven by each core. This 
allows either core to keep the interface In the reset state until It Is ready 
to communicate. 

• Explicit defaults are specified for each parameter, reducing the number of 
parameters needed to fully specify a simple OCP interface. Similarly. 
Interoperability of different OCP interfaces Is simplified by specifying 
default tie-offs for each signal. 

The 2.0 version of the OCP Specification is compatible with the 1.0 version 
with the following exceptions: 

• There have been substantial changes to the burst model. 

- The restriction on byte enables for STRM bursts has been removed. 

- The definition of the burst_aligned parameter has been changed to 
remove the need for all byte enables to be turned on in every transfer. 

• OCP Interfaces without reset are no longer allowed. 

• Ordering of datahandshake phases on multi- threaded OCP Interfaces is 
now constrained to follow the ordering of the request phases across all 
threads. This constraint can be relaxed if the new SDataThreadBusy 
signal is used. 

Document Revision 1.1,1 

This version of the document has been updated with an acknowledgements 
page. 
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1 Overview 



The Open Core Protocol™ (OCPJ defines a high-performance, bus-Indepen- 
dent interface between IP cores that reduces design time, design risk, and 
manufacturing costs for SOC designs. 

An IP core can be a simple peripheral core, a high-performance micropro- 
cessor, or an on-chip communication subsystem such as a wrapped on-chip 
bus. The Open Core Protocol: 

• Achieves the goal of IP design reuse. The OCP transforms IP cores making 
them independent of the architecture and design of the systems in which 
they are used y 

• Optimizes die area by configuring into the OCP only those features needed 
by the communicating cores 

• Simplifies system verification and testing by providing a firm boundary 
around each IP core that can be observed, controlled, and validated 

The approach adopted by the Virtual Socket Interface Alliance's (VSIA) Design 
Working Group on On-Chip Buses (DWGOCB) is to specify a bus wrapper to 
provide a bus-independent Transaction Protocol-level interface to IP cores. 

The OCP is equivalent to VSLVs Virtual Component Interface (VCI). While the 
VCI addresses only data flow aspects of core communications, the OCP Is a 
superset of VCI additionally supporting configurable sideband control 
signaling and test harness signals. The OCP is the only standard that defines 
protocols to unify all of the inter-core communication. 
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OCP Characteristics 



The OCP defines a point-to-point Interface between two communicating enti- 
ties such as IP cores and bus interface modules {bus wrappers). One entity 
acts as the master of the OCP instance, and the other as the slave. Only the 
master can present commands and is the controlling entity. The slave 
responds to commands presented to it either by accepting data from the 
master, or presenting data to the master. For two entities to communicate in 
a peer-to-peer fashion, there need to be two instances of the OCP connecting 
them - one where the first entity is a master, and one where the first entity is 
a slave. 

Figure 1 shows a simple system containing a wrapped bus and three IP core 
entities: one that is a system target, one that is a system initiator, and an 
entity that is both. 

Figure 1 System Showing Wrapped Bus and OCP Instances 

System Initiator System Initiator/Target System Target 



The characteristics of the IP core determine whether the core needs master, 
slave, or both sides of the OCP; the wrapper Interface modules must act as 
the complementary side of the OCP for each connected entity. A transfer 
across this system occurs as follows. A system initiator (as the OCP master) 
presents command, control, and possibly data to Its connected slave {a bus 
wrapper Interface module). The interface module plays the request across the 
on-chip bus system. The OCP does not specify the embedded bus function- 
ality. Instead, the interface designer converts the OCP request into an 
embedded bus transfer. The receiving bus wrapper interface module {as the 
OCP master) converts the embedded bus operation into a legal OCP 
command. The system target (OCP slave) receives the command and takes the 
requested action. 

Each instance of the OCP is configured (by choosing signals or bit widths of a 
particular signal) based on the requirements of the connected entities and is 
independent of the others. For instance, system Initiators may require more 



Bus wrapper 

interface 

module 
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address bits in their OCP instances than do the system targets; the extra 
address bits might be used by the embedded bus to select which bus target 
is addressed by the system initiator. 

The OCP is flexible. There are several useful models for how existing IP cores 
communicate with one another. Some employ pipelining to improve band- 
width and latency characteristics. Others use multiple-cycle access models, 
where signals are held static for several clock cycles to simplify timing anal- 
ysis and reduce implementation area. Support for this wide range of behavior 
is possible through the use of synchronous handshaking signals that allow 
both the master and slave to control when signals are allowed to change. 



Compliance 

For a core to be considered OCP compliant, it must satisfy the following 
conditions: 

L The core must include at least one OCP interface. 

2. The core and OCP interfaces must be described using an KTL 
configuration file with the syntax specified in Chapter 6 on page 65. 

3. Each OCP interface on the core must: 

• Comply with all aspects of the OCP interface specification 

• Have its timing described using a synthesis configuration file following 
the syntax specified in Chapter 7 on page 77. 

4. The following practices are recommended but not required: 

a. Each non-OCP interface on the core should: 

Be described using an interface configuration file with the syntax 
specified in Chapter 5 on page 59. 

Have its timing described using a synthesis configuration file with -the 
syntax specified in Chapter 7 on page 77. 

b. A performance report as specified in Chapter 12 on page 175 (or an 
equivalent report) should be included for the core. 
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2 Theory of Operation 



The Open Core Protocol Interface addresses communications between the 
functional units (or IP cores) that comprise a system on a chip. The OCP 
provides independence from bus protocols without having to sacrifice high- 
performance access to on-chip interconnects. By designing to the interface 
boundary defined by the OCP, you can develop reusable IP cores without 
regard for the ultimate target system. 

Given the wide range of IP core functionality, performance and interface 
requirements, a fixed definition interface protocol cannot address the full 
spectrum of requirements. The need to support verification and test require- 
ments adds an even higher level of complexity to the Interface. To address this 
spectrum of interface definitions, the OCP defines a highly configurable inter- 
face. The OCP's structured methodology Includes all of the signals required to 
describe an IP cores' communications Including data flow, control, and veri- 
fication and test signals. 

This chapter provides an overview of the concepts behind the Open Core 
Protocol, introduces the terminology used to describe the interface and offers 
a high-level view of the protocol. 
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Polnt-to-PoInt Synchronous Interface 

To simplify timing analysis, physical design, and general comprehension, the 
OCP Is composed of uni-directional signals driven with respect to, and 
sampled by the rising edge of the OCP clock. The OCP is fully synchronous 
and contains no multi-cycle timing paths. All signals other than the clock are 
strictly point-to-point. 

Bus Independence 

A core utilizing the OCP can be interfaced to any bus. A test of any bus-inde- 
pendent interface is to connect a master to a slave without an Intervening on- 
chip bus. This test not only drives the specification towards a fully symmetric 
interface but helps to clarify other issues. For Instance, device selection tech- 
niques vary greatly among on-chip buses. Some use address decoders. Others 
generate independent device select signals (analogous to a board level chip 
select). This complexity should be hidden from IP cores, especially since in the 
directly-connected case there is no decode/selection logic* OCP-compliant 
slaves receive device selection information integrated into the basic command 
field. 

Arbitration schemes vaiy widely. Since there is virtually no arbitration In the 
directly-connected case, arbitration for any shared resource Is the sole 
responsibility of the logic on the bus side of the OCP. This permits OCP- 
compliant masters to pass a command field across the OCP that the bus inter- 
face logic converts Into an arbitration request sequence. 

Commands 

There are two basic commands, Read and Write and five command exten- 
sions. The WriteNonPost and Broadcast commands have semantics that are 
similar to the Write command. A WriteNonPost explicitly instructs the slave 
not to post a write. For the Broadcast command, the master indicates that it 
Is attempting to write to several or all remote target devices that are connected 
on the other side of the slave. As such, Broadcast is typically useful only for 
slaves that axe in turn a master on another communication medium (such as 
an attached bus). 

The other command extensions, ReadExcluslve, ReadLlnked and WriteCondl- 
tional, are used for synchronization between system initiators. ReadExclusive 
is paired with Write or WriteNonPost, and has blocking semantics. 
ReadLlnked, used in conjunction with WriteCondltional has non-blocking 
(lazy) semantics. These synchronization primitives correspond to those avail- 
able natively in the instruction sets of different processors. 
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Address/Data 

Wide widths, characteristic of shared on-chip address and data buses, make 
tuning the OCP address and data widths essential for area-efficient Imple- 
mentation. Only those address bits that are significant to the IP core should 
cross the OCP to the slave. The OCP address space is flat and composed of 8- 
blt bytes (octets). 

To increase transfer efficiencies, many IP cores have data field widths signifi- 
cantly greater than an octet. The OCP supports a configurable data width to 
allow multiple bytes to be transferred simultaneously. The OCP refers to the 
chosen data field width as the word size of the OCP. The term word is used in 
the traditional computer system context; that is, a word is the natural 
transfer unit of the block. OCP supports word sizes of power-of-two and non- 
power-of-two as would be needed for a 12-bit DSP core. The OCP address is a 
byte address that is word aligned. 

Transfers of less than a full word of data are supported by providing byte 
enable information that specifies which octets are to be transferred. Byte 
enables are linked to specific data bits [byte lanes). Byte lanes are not associ- 
ated with particular byte addresses. This makes the OCP endian-neutral, able 
to support both big and little-endian cores. 

Pipelining 

The OCP allows pipelining of transfers. To support this feature, the return of 
read data and the provision of write data may be delayed after the presenta- 
tion of the associated request 

Response 

The OCP separates requests from responses. A slave can accept a command 
request from a master on one cycle and respond in a later cycle. The division 
of request from response permits pipelining. The OCP provides the option of 
having responses for Write commands, or completing them immediately 
without an explicit response. 

Burst 

To provide high transfer efficiency, burst support is essential for many IP 
cores. The extended OCP supports annotation of transfers with burst infor- 
mation. Bursts can either include addressing Information for each successive 
command (which simplifies the requirements for address sequencing/burst 
count processing in the slave), or include addressing information only once 
for the entire burst 

ln-band Information 

Cores can pass core-specific information in-band in company with the other 
information being exchanged. In-band extensions exist for requests and 
responses, as well as read and write data. A typical use of in-band extensions 
is to pass cacheable Information or data parity. 
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Threads and Connections 

To support concurrency and out-of-order processing of transfers, the 
extended OCP supports the notion of multiple threads. Transactions within 
different threads have no ordering requirements, and so can be processed out 
of order. Within a single thread of data flow, all OCP transfers must remain 
ordered. 

While the notion of a thread Is a local concept between a master and a slave 
communicating over an OCP, it is possible to globally pass thread information 
from initiator to target using connection Identifiers. Connection information 
helps to Identify the initiator and determine priorities or access permissions 
at the target. 

Interrupts, Errors, and other Sideband Signaling 

While moving data between devices is a central requirement of on-chip 
communication systems, other types of communications are also Important. 
Different types of control signaling are required to coordinate data transfers 
(for instance* high-level flow control) or signal system events (such as inter- 
rupts). Dedicated point-to-point data communication is sometimes required. 
Many devices also require the ability to notify the system of errors that may 
be unrelated to address/data transfers. 

The OCP refers to all such communication as sideband (or out-of-band) 
signaling, since it is not directly related to the protocol state machines of the 
dataflow portion of the OCP. The OCP provides support for such signals 
through sideband signaling extensions. 

Errors are reported across the OCP using two mechanisms. The error 
response code in the response field describes errors resulting from OCP trans- 
fers that provide responses. Write-type commands without responses cannot 
use the in-band reporting mechanism. The second method for reporting 
errors across the OCP uses out-of band error fields. These signals report more 
generic sideband errors, including those associated with posted write 
commands. 
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OCP interface signals are grouped into dataflow, sideband, and test signals. 
The dataflow signals are divided into basic signals, simple extensions, burst 
extensions, and thread extensions. A small set of the signals from the basic 
dataflow group is required In all OCP configurations. Optional signals can be 
configured to support additional core communication requirements, AH side- 
band and test signals are optional. 

The OCP is a synchronous Interface with a single clock signal. All OCP signals 
are driven with respect to, and sampled by, the rising edge of the OCP clock. 
Except for clock, OCP signals are strictly point-to-point and uni-dlrectional. 
The complete set of OCP signals is shown in Figure 4 on page 29. 
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Dataflow Signals 

The dataflow signals consist of a small set of required signals and a number 
of optional signals that can be configured to support additional core commu- 
nication requirements. The dataflow signals are grouped Into basic signals, 
simple extensions {which add such options as byte enables and In-band infor- 
mation), burst extensions {which add support for bursting), and thread 
extensions (which add multi-threading support). 

The naming conventions for dataflow signals use the prefix M for signals 
driven by the OCP master and S for signals driven by the OCP slave. 

Basic Signals 

Table 1 lists the basic OCP signals. Only Clk and MCmd are required. The 
remaining OCP signals are optional. 



Table 1 Basic OCP Signals 



Name 


Width 


Driver 


Function 


Clk 


1 


varies 


OCP clock 


MAddr 


configurable 


master 


Transfer address 


MCmd 


3 


master 


Transfer command 


MDato 


configurable 


master 


Write data 


MDataVolld 


1 


master 


Write data valid 


MRespAccept 


1 


master 


Master accepts 
response 


SCmdAccept 


1 


slave 


" Slave accepts transfer 


SDato 


configurable 


slave 


Read data 


SDatoAccept 


1 


slave 


Slave accepts write 
data 


SResp 


2 


slave 


Transfer response 



Clk 

Clock signal for the OCR All interface signals are synchronous to the 
rising edge of Clk. Clk Is driven by a third entity and serves as an input to 
both the master and the slave. 

MAddr 

The Transfer address, MAddr specifies the slave-dependent address of the 
resource targeted by the current transfer To configure this field Into the 
OCP. use the addr parameter. To configure the width of this field, use the 
addr__wdth parameter. 

MAddr Is a byte address that must be aligned to the OCP word size 
(data_wdth). If the OCP word size is larger than a single byte, the 
aggregate is addressed at the OCP word-aligned address and the lowest 
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order address bits are hardwired to 0. If the OCP word size Is not a power- 
of-2, the address Is the same as it would be for an OCP interface with a 
word size equal to the next larger power-of-2. 

MCmd 

Transfer command. This signal indicates the type of OCP transfer the 
master is requesting. Each non-idle command is either a read or write 
type request depending on the direction of data flow. Commands are 
encoded as follows. 



Table 2 Command Encoding 



MCmd[2:0] 


Command 


Mnemonic 


Request Type 


0 0 


0 


Idle 


IDLE 


(none) 


0 0 


1 


Write 


WR 


write 


0 1 


0 


Read 


RO 


read 


0 1 


1 


ReadEx 


RDEX 


read 


1 0 


0 


ReodLfnked 


RDL 


read 


1 0 


1 


WrtteNonPost 


WRNP 


write 


1 1 


0 


WrlteCondltlonal 


WRC 


write 


1 1 


1 


Broadcast 


BCST 


write 



The set of allowable commands can be limited using the write_enable, 
read_enable, readex_enable, writenonpost_enable, rdlwrc_enabl«, 
and broadcast_enable parameters as described in "Protocol Options" on 
page 47. 

MData 

Write data. This Held carries the write data from the master to the slave. 
The field is configured into the OCP using the mdata parameter and its 
width is configured using the data_wdth parameter. The width is not 
restricted to multiples of 8. 

MDataValid 

Write data valid. When set to 1, this bit Indicates that the data on the 
MData field is valid. Use the datahandshake parameter to configure this 
field Into the OCR 

MRespAccept 

Master response accept The master indicates that it accepts the current 
response from the slave with a value of 1 on the MRespAccept signal. Use 
the respaccept parameter to enable this field Into the OCP. 

SCmdAccept 

Slave accepts transfer. A value of 1 on the SCmdAccept signal indicates 
that the slave accepts the master's transfer request To configure this field 
into the OCP, use the cmdaccept parameter. 
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SData 

This field carries the requested read data from the slave to the master. The 
field Is configured into the OCP using the sdata parameter and Its width 
is configured using the data_wdth parameter. The width Is not restricted 
to multiples of 8. 

SDataAccept 

Slave accepts write data. The slave indicates that It accepts pipelined write 
data from the master with a value of 1 on SDataAccept This signal is 
meaningful only when datahandshake is In use. Use the dataaccept 
parameter to configure this field Into the OCP. 

SResp 

Response field from the slave to a transfer request from the master- The 
field is configured Into the OCP using the resp parameter. Response 
encoding is as follows. 



Table 3 


Response Encoding 




SResp[l:0] 


Response 


Mnemonic 


0 0 


No response 


NULL 


0 1 


Data valid / accept 


DVA 


1 0 


Request foiled 


FAIL 


1 1 


Response error 


ERR 



Simple Extensions 

Table 4 lists the simple OCP extensions. The extensions add to the OCP Inter- 
face address spaces, byte enables, and additional core-specific Information for 
each phase. 



Table 4 Simple OCP Extensions 



Name 


Width 


Driver 


Function 


MAddrSpace 


configurable 


master 


Address space 


MByteEn 


configurable 


master 


Request phase byte enables 


MDatoByteEn 


configurable 


master 


Datahandshake phase write byte 
enables 


MDalalnfo 


configurable 


master 


Additional information transferred 
with the write data 


MReqlnfo 


configurable 


master 


Additional Information transferred 
with the request 


SDatalnfo 


configurable 


siave 


Additional Information transferred 
with the read data 


SRespInfo 


configurable 


slave 


Additional Information transferred 
with the response 
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MAddrSpace 

This field specifies the address space and is an extension of the MAddr 
field that is used to indicate the address region of a transfer. Examples of 
address regions are the register space versus the regular memory space of 
a slave or the user versus supervisor space for a master. 

The MAddrSpace field is configured Into the OCP using the addrspace 
parameter. The width of the MAddrSpace field is configured with the 
addrspace_wdth parameter. While the encoding of the MAddrSpace field Is 
core-specific, it Is recommended that slaves use 0 to Indicate the Internal 
register space. 

MByteEn 

Byte enables. This field Indicates which bytes within the OCP word are 
part of the current transfer. See "Partial Word Transfers" on page 40 for 
more detail on request and datahandshake phase byte enables and their 
relationship. There is one bit In MByteEn for each byte In the OCP word. 
Setting MByteEn In] to 1 indicates that the byte associated with data 
wires [(8n + 7):8n] should be transferred. The MByteEn field Is configured 
into the OCP using the by teen parameter and Is allowed only if data_wdth 
Is a multiple of 8 (that Is, the data width is an Integer number of bytes). 

The allowable patterns on MByteEn can be limited using the 
f orce_aligned parameter as described on page 48. 

MDataByteEn 

Write byte enables. This field Indicates which bytes within the OCP word 
are part of the current write transfer. See "Partial Word Transfers" on 
page 40 for more detail on request and datahandshake phase byte 
enables and their relationship. There is one bit in MDataByteEn for each 
byte in the OCP word. Setting MDataByteEn[nl to 1 indicates that the byte 
associated with MData wires [(8n + 7]:8n] should be transferred. The 
MDataByteEn field Is configured into the OCP using the mdatabyteen 
parameter. Setting mdatabyteen to 1 is only allowed if 
datahandshake__enable Is 1, and only if data_wdth Is a multiple of 8 (that 
is, the data width is an Integer number of bytes). 

The allowable patterns on MDataByteEn can be limited using the 
f orce.aligned parameter as described on page 48. 

MDatalnfo 

Extra information sent with the write data. The master uses this field to 
send additional information sequenced with the write data. Hie encoding 
of the information is core- specific. To be Interoperable with masters that 
do not provide this signal, design slaves to be operable In a normal mode 
when the signal is tied off to its default tie-off value as specified in Table 
12 on page 25. Sample uses are data byte parity or error correction code 
values. Use the mdatainf o parameter to configure this field into the OCP, 
and the mdatainf o_wdth parameter to configure its width. 

This field is divided In two: the low-order bits are associated with each 
data byte, while the high-order bits are associated with the entire write 
data transfer. The number of bits to associate with each data byte is 
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configured using the mdatainf obyte_wdth parameter* The low-order 
mdatainf obyte_wdth bits of MDatalnfo are associated with the 
MData(7:0] byte, and so on. 

Figure 2 MDatalnfo Field 



Associated with entire 
write data transfer 
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MData [(8n+7}:8n] 
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MData [15:8] MData [7:0] 
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MReqlnfo 

Extra information sent with the request. The master uses this field to send 
additional information sequenced with the request. The encoding of the 
information Is core-specific. To be Interoperable with masters that do not 
provide this signal, design slaves to be operable in a normal mode when 
the signal Is tied off to its default tie-off value as specified in Table 12 on 
page 25. Sample uses are cacheable storage attributes or other access 
mode information. Use the reqinf o parameter to configure this field into 
the OCP, and the reqinf o_wdth parameter to configure its width. 

SDatalnfo 

Extra information sent with the read data. The slave uses this field to send 
additional information sequenced with the read data. The encoding of the 
information is core-specific. To be Interoperable with slaves that do not 
provide this signal, design masters to be operable in a normal mode when 
the signal is tied off to Its default tie-off value as specified in Table 12 on 
page 25. Sample uses are data byte parity or error correction code values. 
Use the sdatainf o parameter to configure this field into the OCP, and the 
sdatainf o_wdth parameter to configure its width. 

This field is divided into two pieces: the low-order bits are associated with 
each data byte, while the high-order bits are associated with the entire 
read data transfer. The number of bits to associate with each data byte is 
configured using the sdatainf obyte_wdth parameter. The low-order 
sdatainf obyte_wdth bits of SDatalnfo are associated with the 
SData[7:01 byte, and so on. 
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Figure 3 SDotoInfo Field 
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SRespInfo 

Extra information sent with the response. The slave uses this field to send 
additional information sequenced with the response. The encoding of the 
information is core- specific. To be interoperable with slaves that do not 
provide this signal, design masters to be operable in a normal mode when 
the signal is tied off to its default tie-off value as specified in Table 12 on 
page 25. Sample uses are status or error information such as FIFO full or 
empty indications. Use the r espinf o parameter to configure this field into 
the OCP, and the respinf o_wdth parameter to configure its width. 

Burst Extensions 

Table 5 lists the OCP burst extensions. The burst extensions allow the 
grouping of multiple transfers that have a defined address relationship. 

Table 5 OCP Burst Extensions 



Name 


Width 


Driver 


Function 


MAtomlcLength 


configurable 


master 


Length of atomic burst 


MBurstLength 


configurable 


master 


Burst length 


MBurstPrecIse 


1 


master 


Given burst length Is precise 


MBursiSeq 


3 


master 


Address sequence of burst 


MBurstSingleReq 


1 


master 


Burst uses single request/ multiple 
data protocol 


MDataLast 


1 


master 


Last write data In burst 


MReqLast 


1 


master 


Last request In burst 



SRespLast 1 slave Last response In burst 
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MAtomlcLength 

This field indicates the minimum number of transfers within a burst that 
are to be kept together as an atomic unit when interleaving requests from 
different initiators onto a single thread at the target To configure this field 
into the OCP, use the atomiclength parameter. To configure the width of 
this field, use the atomiclength_wdth parameter. A binaiy encoding of 
the number of transfers is used. A value of 0 is not a legal encoding for 
MAtomlcLength. 

MBurstLength 

The number of transfers in a burst For precise bursts, the value indicates 
the total number of transfers in the burst, and is constant throughout the 
burst For imprecise bursts, the value indicates the best guess of the 
number of transfers remaining (including the current request), and may 
change with every request To configure this field into the OCP, use the 
burstlength parameter. To configure the width of this field, use the 
burstlength_wdth parameter. A binaiy encoding of the number of 
transfers is used. A value of 0 is not a legal encoding for MBurstLength. 

MBurstPrecise 

This field indicates whether the precise length of a burst is known at the 
start of the burst or not When set to 1, MBurstLength indicates the 
precise length of the burst during the first request of the burst To 
configure this field into the OCP, use the burs tprecise parameter. When 
set to 0, MBurstLength for each request is a hint of the remaining burst 
length. 

MBurstSeq 

This field indicates the sequence of addresses for requests in a burst To 
configure this field into the OCP, use the burstseq parameter. The 
encodings of the MBurstSeq field are shown in Table 6. The precise 
definition of the address sequences is described in "Burst Address 
Sequence" on page 42. 

Table 6 MBurstSeq Encoding 



MBurstSeq[2:0] Burst Sequence Mnemonic 



0 


0 


0 


Incrementing 


INCR 


0 


0 


1 


Custom (packed) 


DFLT1 


0 


1 


0 


Wrapping 


WRAP 


0 


1 


1 


Custom (not packed) 


DFLT2 


1 


0 


0 


Exclusive OR 


XOR 


1 


0 


1 


Streaming 


STRM 


1 


1 


0 


Unknown 


UNKN 


1 


1 


1 


Reserved 





MBurstSlngleReq 

The burst has a single request with multiple data transfers. This field 
indicates whether the burst has a request per data transfer, or a single 
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request for all data transfers. To configure this field into the OCP, use the 
burstsinglereq parameter. When this field is set to 0, there is a one-to- 
one association of requests to data transfers; when set to 1, there is a 
single request for all data transfers in the burst 

MDataLast 

Last write data in a burst. This field Indicates whether the current write 
data transfer is the last in a burst To configure this field Into the OCP, 
use the datalast parameter with datahandshake set to L When this 
field is set to 0, more write data transfers are coming for the burst; when 
set to 1, the current write data transfer is the last in the burst 

MReqLast 

Last request in a burst This field indicates whether the current request 
is the last in this burst To configure this field into the OCP, use the 
reqlast parameter. When this field is set to 0, more requests are coming 
for this burst; when set to 1, the current request is the last in the burst 

SRespLast 

Last response In a burst This field indicates whether the current 
response is the last In this burst. To configure this field Into the OCP. use 
the resplast parameter. When the field Is set to 0 ( more responses are 
coming for this burst; when set to 1, the current response is the last in 
the burst 

Thread Extensions 

Table 7 shows a list of OCP thread extensions. The extensions add support for 
multi-threading of the OCP interface. 



Table 7 OCP Thread Extensions 



Name 


Width 


Driver 


Function 


MConnID 


configurable 


master 


Connection Identifier 


MDataThreodID 


configurable 


master 


Write data thread Identifier 


MThreadBusy 


configurable 


master 


Master thread busy 


MThreadID 


configurable 


master 


Request thread Identifier 


SDataThreadBusy 


configurable 


slave 


Slave write data thread busy 


SThreadBusy 


configurable 


slave 


Slave request thread busy 


SThreadID 


configurable 


sieve 


Response thread Identifier 



MConnID 

Connection identifier. This variable-width field provides the binaiy 
encoded connection identifier associated with the current transfer 
request. 

To configure this field use the connid parameter. The field width is 
configured with the connid_wdth parameter. 
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MDataThreadID 

Write data thread Identifier. This variable-width field provides the thread 
identifier associated with the current write data. The field carries the 
binary-encoded value of the thread identifier. 

MDataThreadID Is required If threads is greater than I and the 
datahandshake parameter is set to 1. MDataThreadID has the same 
width as MThreadID and SThreadlD. 

MThreadBusy 

Master thread busy. The master notifies the slave that It cannot accept 
any responses associated with certain threads. The MThreadBusy field is 
a vector (one bit per thread). A value of 1 on any given bit indicates that 
the thread associated with that bit is busy. Bit 0 corresponds to thread 0, 
and so on. The width of the field is set using the threads parameter. It is 
legal to enable a one-bit MThreadBusy interface for a single- threaded 
OCR To configure this field, use the mthreadbusy parameter. 

MThreadID 

Request thread Identifier. This variable-width field provides the thread 
identifier associated with the current transfer request If threads is 
greater than 1, this field is enabled. The field width Is the next whole 
Integer of k^threads). 

SDataThreadBusy 

Slave write data thread busy. The slave notifies the master that it cannot 
accept any new datahandshake phases associated with certain threads. 
The SDataThreadBusy field is a vector, one bit per thread. A value of 1 on 
any given bit indicates that the thread associated with that bit is busy. Bit 
0 corresponds to thread 0, and so on. 

The width of the field is set using the threads parameter. It Is legal to 
enable a one-bit SDataThreadBusy interface for a single-threaded OCP. 
To configure this field, use the sdatathreadbusy parameter. 

SThreadlD 

Response thread identifier. This variable-width field provides the thread 
identifier associated with the current transfer response. If threads is 
greater than 1, this field Is enabled. The field width is the next whole 
Integer of log 2 (threads). 

SThreadBusy 

Slave thread busy. The slave notifies the master that it cannot accept any 
new requests associated with certain threads. The SThreadBusy field is a 
vector, one bit per thread. A value of 1 on any given bit Indicates that the 
thread associated with that bit is busy. Bit 0 corresponds to thread 0, and 
so on. The width of the field is set using the threads parameter. It Is legal 
to enable a one-bit SThreadBusy interface for a single-threaded OCP. To 
configure this field, use the sthreadbusy parameter. 
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Sideband Signals 

Sideband signals are OCP signals that are not part of the dataflow phases, 
and so can change asynchronously with the request /response flow but are 
still synchronous to the rising edge of Clk. Sideband signals convey control 
information such as reset, interrupt, error, and core-specific flags. They also 
exchange control and status information between a core and an attached 
system. All sideband signals are optional. 

Table 8 shows a list of the sideband extensions to the OCP, 



Table 8 Sideband OCP Signals 



Name 


Width 


Driver 


Function 


MError 


1 


master 


Master Error 


MFlog 


configurable 


master 


Master flags 


MReset.n 


1 


master 


Synchronous master reset 


SError 


1 


slave 


Slave error 


SFlog 


configurable 


sfave 


Slave flags 


Slnteraipt 


1 


slave 


Slave Interrupt 


SReset_n 


1 


stave 


Synchronous slave reset 


Control 


configurable 


system 


Core control Information 


ControiBusy 


1 


core 


Hold control Information 


ControJWr 


1 


system 


Control Information has been written 


Status 


configurable 


core 


Core status Information 


StatusBusy 


1 


core 


Status Information Is not consistent 


StatusRd 


1 


system 


Status information has been read 



Reset, Interrupt, Error, and Core-Specific Flag Signals 

MError 

Master error. When the MErTor signal is set to 1, the master notifies the 
slave of an error condition. The MError field Is configured with the merror 
parameter. 

MFlag 

Master flags. This variable-width set of signals allows the master to 
communicate out-of-band Information to the slave. Encoding is 
completely core-specific. 

To configure this field into the OCP, use the mf lag parameter. To 
configure the width of this field, use the mflag_wdth parameter. 

MReset^n 

Synchronous master reset. The MReset_n signal Is active low, as shown 
in Table 9. The MReset.n field is enabled by the mreset parameter. 
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Table 9 MReset Signal 

MReseMi Function 

0 Reset Active 

1 Reset Inactive 



SError 

Slave error* With a value of 1 on the SError signal the slave Indicates an 
error condition to the master. The SError field Is configured with the 
serror parameter. 

SFlag 

Slave flags. This variable-width set of signals allows the slave to 
communicate out-of-band Information to the master. Encoding Is 
completely core- specific. 

To configure this field into the OCP, use the sf lag parameter. To 
configure the width of this field, use the sf lag_wdth parameter. 

Slnterrupt 

Slave interrupt. The slave may generate an Interrupt with a value of 1 on 
the Slnterrupt signal. The Slnterrupt field is configured with the 
interrupt parameter. 

SReset_n 

Synchronous slave reset The SReset.n signal is active low, as shown in 
Table 10. The SReset_n field is enabled by the sreset parameter. 

Table W SReset Signal 

SResctj Function 

0 Reset Active 

1 Reset Inactive 



Control and Status Signals 

The remaining sideband signals are designed for the exchange of control and 
status information between an IP core and the rest of the system. They make 
sense only in this environment, regardless of whether the IP core acts as a 
master or slave across the OCP interface. 

Control 

Core control information. This variable-width field allows the system to 
drive control information Into the IP core. Encoding Is core-specific. 

Use the control parameter to configure this field Into the OCP. Use the 
control_wdth parameter to configure the width of this field. 
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ControlBusy 

Core control busy. When this signal Is set to 1 1 the core tells the system 
to hold the control field value constant Use the controlbusy parameter 
to configure this field Into the OCP. 

ControlWr 

Core control event This signal Is set to 1 by the system to Indicate that 
control Information Is written by the system. Use the control wr 
parameter to configure this field into the OCP, 

Status 

Core status Information. This variable- width field allows the IP core to 
report status Information to the system. Encoding is core-specific. 

Use the status parameter to configure this field Into the OCP. Use the 
status_wdth parameter to configure the width of this field. 

Statu sBusy 

Core status busy. When this signal Is set to 1, the core tells the system to 
disregard the status field because it may be inconsistent Use the 
statusbusy parameter to configure this field Into the OCP. 

StatusRd 

Core status event This signal Is set to 1 by the system to indicate that 
status Information is read by the system. To configure this field Into the 
OCP, use the statusrd parameter. 



Test Signals 

The test signals add support for scan, clock control, and IEEE 1 149. 1 {JTAG). 
All test signals are optional. 



Table 11 Test OCP Signals 



Name 


Width 


Driver 


Function 


Scanctrl 


configurable 


system 


Scan control signals 


Scanln 


configurable 


system 


Scan data In 


Scanout 


configurable 


core 


Scan data out 


ClkByp 




system 


Enable clock bypass mode 


TestClk 




system 


Test clock 


TCK 




system 


Test clock 


TDI 




system 


Test data In 


TDO 




core 


Test data out 


IMS 




system 


Test mode select 


TRST.N 




system 


Test reset 
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Scan Interface 

The Scanctrl, Scanin, and Scanout signals together form a scan Interface into 
a given IP core. 

Scanctrl 

Scan mode control signals. Use this variable width field to control the scan 
mode of the core* Set scanport to 1 to configure this field into the OCP 
interface. Use the scanctrl_wdth parameter to configure the width of 
this field. 

Scanin 

Scan data In for a core's scan chains. Use the scanport parameter, to 
configure this field into the OCP interface and scanport_wdth to control 
its width. 

Scanout 

Scan data out from the core's scan chains. Use the scanport parameter 
to configure this field into the OCP interface and scanport_wdth to 
control Its width. 



Clock Control Interface 

The ClkByp and TestClk signals together form the clock control Interface into 
a given IP core. This interface Is used to control the core's clocks during scan 
operation. 

ClkByp 

Enable clock bypass signal. When set to 1, this signal instructs the core 
to bypass the external clock source and use TestClk instead. Use the 
clkctrl_enable parameter to configure this signal into the OCP 
interface. 

TestClk 

A gated test clock. This clock becomes the source clock when ClkByp is 
asserted during scan operations. Use the clkctrl.enable parameter to 
configure this signal Into the OCP interface. 

Debug and Test Interface 

The TCK. TDI, TOO, TMS, and TRST_N signals together form an IEEE 1149 
debug and test interface for the OCP. 

TCK 

Test clock as defined by IEEE 1149.1. Use the jtag_enable parameter to 
add this signal to the OCP Interface. 

TDI 

Test data in as defined by IEEE 1 1 49. 1. Use the j tag.enable parameter 
to add this signal to the OCP interface. 

TOO 

Test data out as defined by IEEE 1149.1. Use the jtag_enable parameter 
to add this signal to the OCP interface. 
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TMS 

Test mode select as dellned by IEEE 1149,1. Use the jtag_enable 
parameter to add this signal to the OCP interface. 

TRSTLN 

Test logic reset signal. This is an asynchronous active low reset as defined 
by IEEE 1149.1. Use the jtagtrst_enable parameter to add this signal 
to the OCP interface. 



Signal Configuration 

The set of signals making up the OCP interface Is configurable to match the 
characteristics of the IP core. Throughout this chapter, configuration param- 
eters were mentioned that control the existence and width of various OCP 
fields. Table 12 on page 25 summarizes the configuration parameters, sorted 
by interface signal group. For each signal, the table also specifies the default 
constant tie-off, which is the inferred value of the signal if It Is not configured 
into the OCP Interface and if no other constant tie-off is specified. 

For the MRespAccept SCmdAccept, SDataAccept. MReset.n, SReset_n, 
ControlBusy, and StatusBusy signals, the default tie-off is also the only legal 
tie-off. 



Table 12 OCP Signal Configuration Parameters 



Group 


Signal 


Parameter to add 
signal to interface 


Parameter to 
control width 


Default 
Tie-off 


Basic 


Clk 


Required 


Fixed 


n/a 




MAddr 


addr 


addr.wdth 


0 




MCmd 


Required 


Fixed 


n/a 




MData 


mdata 


daia.wdth 


0 




MDataValld 


datahandshake 


Fixed 


n/a 




MRespAccept 1 


respaccept 


Fixed 


1 




SCmdAccept 


cmdaccept 


Fixed 


1 




SData 1 


sdata 


daia.wdth 


0 




SDataAccept 2 


dataaccept 


Fixed 


1 




SResp 


resp 


Fixed 


Null 


Simple 


MAddrSpace 


oddrspace 


addrspace_wdth 


0 




MByteEn 3 


byteen 


data.wdth 


all Is 




MDataByteEn 4 


mdatabyteen 


data.wdth 


all Is 




MDatalnfo 


rndctainfo 


mdatainfo_wdth 5 


0 




MReqlnfo 


reqlnfo 


reqinfo_wdth 


0 
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Group 


Signal 


ruruiniricr iv uuu 

signal to interface 


-rarumeier w 
control width 


Tin fVi u It 
IJ CI Quit 

Tie-off 




SDatalnfo 1 


sdatalnfo 


sdotaInfo_wdth 6 


0 




SRespinfo^ 


resplnfo 


resplnfo.wdth 


0 


Burst 


MAtomlcLength 


atomlclength 


atomfclength_wd1tt 


1 




MBurslLength 


burstlength 


burstlength.wdth 


1 




MBurstPrecise 


burstpreclse 


Fixed 


1 




MBurstSeq 


burstseq 


Rxed 


INCR 




MBurstSingleReq 7 


burstsinglereq 


Fixed 


0 




MDatalasI 8 


datalast 


Fixed 


n/a 




MReqLast 


reqlast 


Fixed 


n/a 




SRespLast 1 


respfast 


Fixed 


n/a 


Thread 


MConnID 


connld 


connld.wdth 


0 




MDataThreadlD 9 


threads>l and 
datahandshoke 


threads 


0 




MThreadBusy 10 


mthreadbusy 


threads 


0 




MThreadlD 


threads>l 


threads 


0 




SDataThreadBusy 11 


sdatathreodbusy 


threads 


0 




SThreodBusy 12 


sthreodbusy 


threads 


0 




SThreodID 


threads>l and resp 


threads 


0 


Sideband 


Control 


control 


controLwdth 


0 




ControlBusy 13 


controlbusy 


Fixed 


0 




ControfWr 14 


control wr 


Rxed 


n/a 




MPrror 
■ v it. j i ui 


morrnr 


rixea 


u 




MRnn 




mnOy^waTTi 


0 




MPp^At n 
i v 1 1 \ c- o c? i_j i 


IT II CdQl 


rixea 


J 




SError 


Ct7l 1 KJt 


riAUU 


U 




SFlag 


sflag 


sflag_wdth 


0 




Sinterrupt 


Interrupt 


Fixed 


0 




SReseLn 


sreset 


Fixed 


1 




Status 


status 


status_wdth 


0 




StatusBusy 15 


stotusbusy 


Fixed 


0 




StatusRd 16 


statusrd 


Fixed 


n/a 
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Signal 


Parameter to add 
signal to interface 


Parameter to 
control width 


Default 
Tie-off 


ClkByp 


clkctrLenable 


Fixed 


n/a 


Scanctrl 


scanport 


scanctrLwdth 


n/a 


Sconin 


scanport 


scanport_wdth 


n/a 


Scanout 


scanport 


scanport.wdth 


n/a 


TCK 


Jtag_enable 


Fixed 


n/a 


TO! 


Jtog_enable 


Rxed 


n/a 


TDO 


jtag.enable 


Fixed 


n/a 


TestClk 


clkctrLenable 


Fixed 


n/a 


IMS 


Jtag.enable 


Fixed 


n/a 


TRSLN 


Jtagtrst_enabie 


Fixed 


n/a 



1 MRespAccept. SData, SDatalnfo. SResplnfo, and SRespLast may be Included only If the resp 
parameter is set to 1. 

2 SDataAccept can be Included only If datahandshake Is set to 1 . 

3 MByteEn has a width of data.wdth/8 and can only be Included when either mdata or sdata is 
set to 1 and data_wdth is an integer multiple of 8, 

4 MDataByleEn has a width of data_wdth/8 and can only be included when indata is set to 1, 
datahandshake is set to 1, and data_wdth is an Integer mulUple of 8. 

5 rodatainfo_wdth must be greater than or equal to mdacainfobyte_wdth * data_vdth/8 and 
can be used only if data.wdth Is a multiple of 8. mdatainf obyte_wdth specifies the 
partitioning of MDatalnfo into transfer-specillc and per-byte fields, 

6 sdatainfo_wdth must be greater than or equal to sdatainfobyte_wdth * data_wdth/8 and 
can be used only If data_wdth is a multiple of 8. sdatainfobyte_wdth specifies the 
partitioning of SDatalnfo into transfer-specillc and per-byte fields. 

7 If any write-type commands are enabled, MBurstStngteReq can only be included when 
datahandshake is set to 1. 

8 MDataLast can be included only if datahandshake is set to 1. 

9 MDataThreadlD is Included if threads Is greater than 1 and the datahandshake parameter is 
set to 1. 

10 MThreadBusy has a width equal to threads. It may be included for single-threaded OCP 
Interfaces. 

1 1 SDataThreadBusy has a width equal to threads. It may be Included for single- threaded OCP 
Interfaces. 

12 SThreadBusy has a width equal to threads. It may be included for single-threaded OCP 
interfaces. 

13 ControlBusy can only be included If both Control and ControlWr exist 

14 ControlWr can only be included If Control exists. 

15 StatusBusy can only be Included tf Status exists. 

16 StatusRd can only be included if Status exists. 
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Signal Directions 



Figure 4 on page 29 summarizes all OCP signals* The direction of some 
signals (for example, MCmd) depends on whether the module acts as a master 
or slave, while the direction of other signals (for example. Control) depends on 
whether the module acts as a system or a core. The combination of these two 
choices provides four possible module configurations as shown in Table 13. 

Table 13 Module Configuration Based on Signal Directions 

Acts as Core or has . A - A 
K7 c 4 . Acts as System 
No System Signals _ 

Acts as OCP Master Master System master 

Acts as OCP Slave Sfave System slave 



For example, if a module acts as OCP master and also as system, it Is desig- 
nated a system master. There is also a monitor type that observes all OCP 
signals. The permitted connectivity between interface types is shown in 
Table 14. 



Table 14 Interface Types 





Connect To 


Cannot Connect To 


Master 


System slave 
Slave 


Master 

System master 


Slave 


System master 
Master 


Slave 

System slave 


System master 


Slave 

System slave 


Master 

System master 


System slave 


Master 

System master 


Slave 

System slave 


Monitor 


Any except monitor 


Monitor 



The Clk signal is special in that it is always supplied by a third (external) 
entity that Is neither of the two modules connected through the OCP interface. 
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Figure A OCP Signal Summary 
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This chapter defines the semantics of the OCP protocol by assigning meanings 
to the signal encodings described In the preceding chapter. Figure 5 provides 
a graphic view of the hierarchy of elements that compose the OCP. 

Figure 5 Hierarchy of Elements 
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Group Timing information 
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Signal Groups 

Some OCP fields are grouped together because they must be active at the 
same time. The data flow signals are divided into three signal groups: request 
signals, response signals, and datahandshake signals. A list of the signals 
that belong to each group is shown in Table 15. 

Table 15 OCP Signal Groups 



Group 


Signal 


Condition 




Request 


MAddr 


always 






MAddrSpace 


always 






MAtorr.lcLength 


always 






MBursttength 


always 






MBurstPreclse 


always 






MBurstSeq 


always 






MBurstSIngleReq 


always 






MByteEn 


always 






MCmd 


always 






MConnID 


always 






MData* 


datahandshake = 


0 




MDatalnfo* 


datahandshake = 


0 




MReqlnfo 


always 






MReqLast 


always 






MThreadlD 


always 




Resoons© 




a i ways 






oLJaTainro 


always 






SResp 


always 






SRespInfo 


always 






SRespLast 


always 






SThreadID 


always 




Datahandshake 


MData* 


datahandshake = 


1 




MDataByteEn 


always 






MDatalnfo* 


datahandshake = 


1 




MDataLast 


always 






MDataThreadID 


always 






MDataValid 


always 





* MData and MDaialnfo belong to the request group, unless the datahandshake configuration 
parameter is enabled. In that case they belong to the datahandshake group. 
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Combinational Dependencies 

It is legal for some signal or signal group outputs to be derived from inputs 
without an intervening latch point, that Is combinational^. To avoid combi- 
national loops, other outputs cannot be derived in this manner. Figure 6 
describes a partial order of combinational dependency. For any arrow shown, 
the signal or signal group can be derived combinationally from the signal at 
the point of origin of the arrow or another signal earlier in the dependency 
chain. No other combinational dependencies are allowed. 

Figure 6 Lego! Combinational Dependencies Between Signals and Signal Groups 



Slave 
Master 




Combinational paths are not allowed within the sideband and test signals, or 
between those signals and the data flow signals. The only legal combinational 
dependencies are within the data flow signals. Data flow signals, however, 
may be combinationally derived from MReset_n and SReset_n. 

For timing purposes, some of the allowed combinational paths are designated 
as preferred paths and are described in Table 29 on page 163, 



Signal Timing and Protocol Phases 

This section specifies when a signal can or must be valid. 



Dataflow Signals 

Signals in a signal group must all be valid at the same time. 

• The request group is valid whenever a command other than Idle is 
presented on the MCmd field. 

• The response group is valid whenever a response other than Null is 
presented on the SResp field. 

• The datahandshake group is valid whenever a 1 is presented on the 
MDataValid field. 
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The accept signal associated with a signal group is valid only when that group 
is valid. 

• The SCmdAccept signal is valid whenever a command other than Idle Is 
presented on the MCmd field, 

• The MRespAccept signal is valid whenever a response other than Null is 
presented on the SResp field. 

• The SDataAccept signal Is valid whenever a 1 is presented on the 
MDataValid field. 

The signal groups map on a one-to-one basis to protocol phases. All signals 
In the group must be held steady from the beginning of a protocol phase until 
the end of that phase. Outside of a protocol phase, all signals In the corre- 
sponding group {except for the signal that defines the beginning of the phase) 
are "don't care". 

In addition, the MData and MDatalnfo fields are a "don't care* 1 during read- 
type requests, and the SData and SDatalnfo fields are a "don't care" for 
responses to write- type requests. Non-enabled data bytes in MData and bits 
in MDatalnfo as well as non- enabled bytes In SData and bits in SDatalnfo are 
a "don't care". The MDataByteEn field is a "don't care* during read-type trans- 
fers. If MDataByteEn is present, the MByteEn field Is a "don't care" during 
write- type transfers. 

• A request phase begins whenever the request group becomes active. It 
ends when the SCmdAccept signal is sampled by Clk as 1 during a request 
phase. 

• A response phase begins whenever the response group becomes active. It 
ends when the MRespAccept signal is sampled by Clk as 1 during a 
response phase. 

If MRespAccept is not configured Into the OCP Interface (respaccept » 0} 
then MRespAccept is assumed to be on; that Is the response phase is 
exactly one cycle long. 

• A datahandshake phase begins whenever the datahandshake signal 
group becomes active. It ends when the SDataAccept signal is sampled by 
Clk as 1 during a datahandshake phase. 

For all phases, it is legal to assert the corresponding accept signal In the cycle 
that the phase begins, allowing the phase to complete in a single cycle. 

Phases fn a Transfer 

An OCP transfer consists of several phases as shown in Table 16. Every 
transfer has a request phase. Read-type requests always have a response 
phase. For write-type requests, the OCP can be configured with or without 
responses or datahandshake. Without a response, a write-type request 
completes upon completion of the request phase {posted write model). 
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Table 16 Phases In a Transfer for MBurstSlnqleReq set to 0 



MCmd 


Phases 


Condition 


Read, ReadEx 
ReodUnked 


Request, response 


always 


Write, Broadcast 


Request 


datahandshake = 0 
writeresp_enable = 0 


Write, WriteNonPost, 

WrlteCondlnonal. 

Broadcast 


Request, response 


datahandshake =0 
writeresp.enable = 1 


Write, Broadcast 


Request, datahandshake 


datahandshake = 1 
writeresp_enab!e = 0 


Write. WriteNonPost. 

WriteCondltlonaL 

Broadcast 


Request, datahandshake. response 


datahandshake = 1 
writeresp.enabie = 1 


Single request / multiple data bursts, described In "Single Request / Multiple 
Data Bursts (Packets)" on page 45, have a single request phase and multiple 
data transfer phases as shown in Table 17. 


Table 1 7 Phases In a Transfer for MBurstSlnqleReq set to 1 




MCmd 


Phases 


Condition 


Read 


Request, L* response 


always 


Write. Broadcast 


Request. L* datahandshake 


datahandshake = 1 
wrlteresp.enable = 0 


Write, WriteNonPost. 
Broadcast 


Request. L* datahandshake, response 


datahandshake = 1 
writeresp_enable = 1 


*L refers to the burst length 





Phase Ordering Within a Transfer 

The OCP Is causal: within each transfer a request phase must precede the 
associated datahandshake phase which in turn, must precede the associated 
response phase. The specific constraints are: 

• A datahandshake phase cannot begin before the associated request phase 
begins, but can begin in the same Clk cycle. 

• A datahandshake phase cannot end before the associated request phase 
ends, but can end in the same Clk cycle. 

• A response phase cannot begin before the associated request phase 
begins, but can begin In the same Clk cycle. 

• A response phase cannot end before the associated request phase ends, 
but can end in the same Clk cycle. 
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• If there is a datahandshake phase and a response phase, the response 
phase cannot begin before the associated datahandshake phase (or last 
datahandshake phase for single request/multiple data bursts) begins, but 
can begin in the same Clk cycle. 

• If there is a datahandshake phase and a response phase, the response 
phase cannot end before the associated datahandshake phase (or last 
datahandshake phase for single request/multiple data bursts) ends, but 
can end in the same Clk cycle. 

Phase Ordering Befween Transfers 

The ordering of transfers is determined by the ordering of their request 
phases. 

• Since two phases of the same type belonging to different transfers both 
use the same signal wires, the phase of a subsequent transfer cannot 
begin before the phase of the previous transfer has ended. If the first 
phase ends in cycle x, the second phase can begin in cycle x + 1. 

• The ordering of datahandshake phases must follow the order set by the 
request phases Including multiple datahandshake phases for single 
request / multiple data bursts. 

• The ordering of response phases must follow the order set by the request 
phases including multiple response phases for single request / multiple 
data bursts* 

• For single request / multiple data bursts, a request or response phase is 
shared between multiple transfers. Each Individual transfer must obey 
the ordering rules described in "Phase Ordering Within a Transfer* on 
page 35, even when a phase Js shared with another transfer. 

• Where no phase ordering is specified, by the previous rules, the effect of 
two transfers that are addressing the same location (as specified by 
MAddr, MAddrSpace, and MByteEn) must be the same as If the two 
transfers were executed In the same order but without any phase overlap. 
This ensures that read/write hazards yield predictable results. 

For example, on an OCP interface with datahandshake enabled, a read 
following a write to the same location cannot start its response phase until 
the write has started its datahandshake phase, otherwise the latest write 
data cannot be returned for the read. 

Ungrouped Signals 

Signals not covered in the description of signal groups and phases are 
MThreadBusy, SDataThreadBusy, and SThreadBusy. Without further 
protocol restriction, the cycle timing of the transition of each bit that makes 
up each of these three fields Is not specified relative to the other dataflow 
signals. This means that there Is no specific time for an OCP master or slave 
to drive these signals, nor a specific time for the signals to have the desired 
flow-control effect. It follows that without further restriction, MThreadBusy, 
SDataThreadBusy, and SThreadBusy can only be treated as a hint It is 
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possible to force stricter semantics using the protocol configuration parame- 
ters mthreadbusy_exact, sdatathreadbusy_exact, and 
sthreadbusy_exact in the following way: 

• If n\threadbusy_exact is enabled for a master and the master is unable 
to accept a response on a thread in a given cycle, it must set the 
MThreadBusy bit for that thread to 1 in that cycle. If a response is 
presented on a thread for which MThreadBusy is not set to 1 in the 
current cycle, it must be accepted by the master in that cycle. 

If mthreadbusy_ exact is enabled for a slave, the slave must take the 
MThreadBusy signal into account for the thread selection of the current 
cycle, that is, It must not present a response on a thread for which the 
corresponding MThreadBusy bit is set to 1 in the cycle. 

• If sdatathreadbusy__exac t Is enabled for a slave that is unable to accept 
a datahandshake phase on a thread in a given cycle, it must set the 
SDataThreadBusy bit for that thread to 1 in that cycle. If a 
datahandshake phase is presented on a thread for which 
SDataThreadBusy is not set to 1 in the current cycle, it must be accepted 
by the slave in that cycle. 

If sdatathreadbusy_exact is enabled for a master, the master must take 
the SDataThreadBusy signal into account for the thread selection of the 
current cycle, that Is, it must not present a datahandshake phase on a 
thread for which the corresponding SDataThreadBusy bit Is set to 1 in 
this cycle. 

• If s threadbusy_exact Is enabled for a slave that is unable to accept a 
command on a thread In a given cycle, it must set the SThreadBusy bit 
for that thread to 1 In that cycle. If a command is presented on a thread 
for which SThreadBusy is not set to 1 in the current cycle, it must be 
accepted by the slave in that cycle. 

If sthreadbusy_exact is enabled for a master, the master must take the 
SThreadBusy signal into account for the thread selection of the current 
cycle, that is, it must not present a command on a thread for which the 
corresponding SThreadBusy bit Is set to 1 in this cycle. 

A multi-threaded OCP interface is guaranteed to be non-blocking only if all of 
the following conditions are satisfied: 

1. cmdaccept is set to 0 and SCmdAccept is tied off to a value of 1. 

2. If sthreadbusyissetto 1, sthreadbusy.exact Is set to 1 for both master 
and slave. 

3. If datahandshake is set to 1 , dataaccept is set to 0 and SDataAccept Is 
tied off to a value of 1 . 

4. If datahandshake is set to 1 and sdatathreadbusy is set to 1, 
sdatathreadbusy_exact is set to 1 for both master and slave. 

5. respaccept is set to 0 and MRespAccept Is tied off to a value of 1. 

6. If mthreadbusy Is set to 1 , mthreadbusy_exact Is set to 1 for both master 
and slave. 
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Sideband and Test Signals 
Reset 

The OCP Interface provides an interface reset signal for each master and 
slave. At least one of these signals must be present If both signals are 
present, the composite reset state of the interface is derived as the logical AND 
of the two signals (that is, the interface is in reset as long as one of the two 
resets is asserted). 

Once one or both reset signals are sampled asserted by the rising edge of Clk, 
all incomplete transactions, transfers and phases are terminated and both 
master and slave must transition to a state where there are no pending OCP 
requests or responses. MReset_n and SReset.n must be asserted for at least 
16 cycles of Clk to ensure that the master and slave reach a consistent 
internal state. When one or both of the reset signals are asserted in a given 
cycle, all other OCP signals must be Ignored in that cycle. The master and 
slave must each be able to reach their reset state regardless of the values 
presented on the OCP signals. If the master or slave require more than 16 
cycles of reset assertion, the requirement must be documented in the IP core 
specifications. 

At the clock edge that all reset signals present are sampled deasserted, all 
OCP interface signals must be valid. In particular, it Is legal for the master to 
begin its first request phase in the same clock cycle that reset is deasserted. 

Interrupt, Error, and Core Flags 

There is no specific timing associated with SInterrupt, SError, MFlag, MError, 
and SFlag. TTie timing of these signals Is core- specific. 

Status and Control 

The following rules assure that control and status Information can be 
exchanged across the OCP without any combinational paths from inputs to 
outputs and at the pace of a slow core. 

• Control must be held steady for a full cycle after the cycle in which It has 
transitioned, which means It cannot transition more frequently than eveiy 
other cycle. If ControlBusy was sampled active at the end of the previous 
cycle. Control must not transition in the current cycle. In addition. 
Control must be held steady for the first two cycles after reset is 
deasserted. 

• If Control transitions in a cycle, ControlWr (if present) must be driven 
active for that cycle. ControlWr following the rules for Control, cannot be 
asserted in two consecutive cycles. 

• ControlBusy allows a core to force the system to hold Control steady. 
ControlBusy may only start to be asserted immediately after reset, or in 
the cycle after ControlWr is asserted, but can be left asserted for any 
number of cycles. 
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• While StatusBusy Is active. Status Is a "don't care", StatusBusy enables a 
core to prevent the system from reading the current status information. 
While StatusBusy is active the core may not read Status. StatusBusy can 
be asserted at any time and be left asserted for any number of cycles. 

• StatusRd is active for a single cycle every time the status register is read 
by the system. If StatusRd was asserted in the previous cycle, it must not 
be asserted in the current cycle, so it cannot transition more frequently 
than every other cycle. 

Test Signals 

Scanin and Scanout are "don't care" while Scanctrl is inactive {but the 
encoding of inactive for Scanctrl is core-specific). 

TestClk is "don't care" while ClkByp is 0. 

The timing ofTRSTJM, TCK, TMS, TO I, and TOO is specified in the IEEE 1 149 
standard. 



Transfer Effects 

A successful transfer is one that completes without error. For write-type 
requests without responses, there can be no in-band error indication. For all 
other requests, a non-ERR response (that is, a DVA or FAIL response) indi- 
cates a successful transfer. The FAIL response Is legal only for 
WriteConditional commands. This section defines the effect that a successful 
transfer has on a slave. The request acts on the addressed location, where the 
term address refers to the combination of MAddr, MAddrSpace, and 
MByteEnable (or MDataByteEn. if applicable). Two addresses are said to 
match if they are Identical in all components. Two addresses are said to 
conflict, if the mutual exclusion (lock or monitor) logic is built to alias the two 
addresses into the same mutual exclusion unit The transfer effects of each 
command are: 

Idle 

None. 
Read 

Returns the latest value of the addressed location on the SData field. 
ReadEx 

Returns the latest value of the addressed location on the SData field. Sets 
a lock for the Initiating thread on that location. The next request on the 
thread that issued a ReadEx must be a Write or WriteNonPost to the 
matching address. Requests from other threads to a conflicting address 
that is locked are blocked from proceeding until the lock is unset If the 
ReadEx request returns an ERR response, it is slave-specific whether the 
lock Is actually set or not 

ReadLlnked 

Returns the latest value of the addressed location on the SData field. Sets 
a reservation tag in a monitor for the corresponding thread on at least that 



OCP-IP Confidential 



40 Open Core Protocol Specification 



location. Requests of any type from any thread to a conflicting address 
that is reserved are not blocked from proceeding, but may clear the 
reservation tag, 

Write/WrlteNonPost 

Places the value on the MData field in the addressed location. Unlocks 
access to the matched address if locked by a ReadEx. Clears the 
reservation tags on any conflicting addresses set by other threads. 

WriteConditlonal 

If a reservation tag Is set for the matching address and for the 
corresponding thread, the write is performed as It would be for a Write or 
WriteNonPost. Simultaneously, the reservation tag is cleared for all 
threads on any conflicting address. If no reservation tag is set for the 
corresponding thread, the write is not performed, a FAIL response is 
returned, and no reservation tags are cleared. 

Broadcast 

Places the value on the MData field in the addressed location that may 
map to more than one slave in a system-dependent way. Broadcast clears 
the reservation tags on any conflicting addresses set by other threads. 

If a transfer Is unsuccessful, the effect of the transfer is unspecified. It is up 
to higher-level protocols to determine what happened and handle any clean- 
up. 

The synchronization commands ReadEx / Write, ReadEx / WriteNonPost, 
and ReadLinked / WrlteConditional have special restrictions with regard to 
data width conversion and partial words. In systems where these commands 
are sent through a bridge or interconnect that performs wlde-to-narrow data 
width conversion between two OCP Interfaces, the initiator must Issue only 
commands within the subset of partial words that can be expressed as a 
single word of the narrow OCP interface. For maximum portability, single- 
byte synchronization operations are recommended. 

Partial Word Transfers 

An OCP Interface may be configured to Include partial word transfers by using 
either the MByteEn field, or the MDataByteEn field, or both. 

• If neither field is present, then only whole word transfers are possible. 

• If only MByteEn is present, then the partial word is specified by this field 
for both read type transfers and write type transfers as part of the request 
phase. 

• If only MDataByteEn Is present, then the partial word Is specified by this 
field for write type transfers as part of the datahandshake phase, and 
partial word reads are not supported. 

• If both MByteEn and MDataByteEn are present, then MByteEn specifies 
partial words for read transfers as part of the request phase, and 
MDataByteEn specifies partial words for write transfers as part of the 
datahandshake phase. 
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It is legal to use a request with all byte enables deasserted. Such requests 
must follow all the protocol rules, except that they are treated as no-ops by 
the slave: the response phase signals SData and SDatalnfo are "don't care" for 
read-type commands, and nothing is written for write-type commands. 

Posting Semantics 

The OCP includes a basic Write command, Typically, a system designer 

decides what write completion model to assign to a core's write commands. If 

the OCP is configured to not respond to write-type commands 

(wri teresp_enable set to 0), a posted write completion model is assumed. It 

Is also possible to achieve a non-posted model by not accepting the command 

until the write completes, but this de-pipelines the OCP interface and is not 

recommended. 

If the OCP is configured to respond to write-type commands 
(writeresp_enable set to 1). either a posted or a non-posted write comple- 
tion model can be used. For cores that need to determine on a per-transfer 
basis whether a write Is to be treated as posted or non-posted, the OCP 
provides the WriteNonPost command. 



Endianness 

An OCP Interface by itself Is inherently endian-neutral. Data widths must 
match between master and slave, addressing is on an OCP word granularity, 
and byte enables are tied to byte lanes (data bits) without tying the byte lanes 
to specific byte addresses. 

The issue of endianness arises in the context of multiple OCP interfaces, 
where the data widths of the initiator of a request and the final target of that 
request do not match. Examples are a bridge or a more general interconnect 
used to connect OCP-based cores. 

When the OCP interfaces differ in data width, the interconnect must associate 
an endianness with each transfer. It does so by associating byte lanes and 
byte enables of the wider OCP with least- significant word address bits of the 
narrower OCR Packing rules, described in Tacking" on page 43 must also be 
obeyed for bursts. 

OCP interfaces can be designated as little, big, both, or neutral with respect 
to endianness. This Is specified using the protocol parameter endian 
described in "Endianness* on page 49. A core that is designated as both typi- 
cally represents a device that can change endianness based upon either an 
Internal configuration register or an external Input. A core that is designated 
as neutral typically represents a device that has no inherent endianness. This 
indicates that either the association of an endianness Is arbitraiy {as with a 
memory, which traditionally has no inherent endianness) or that the device 
only works with full-word quantities (when byteen and mdatabyteen are set 
to 0). 
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When all cores have the same endianness, an interconnect should match the 
endianness of the attached cores. The details of any conversion between cores 
of different endianness is implementation-specific* 



Burst Definition 

A burs* is a set of transfers that are linked together into a transaction having 
a defined address sequence and number of transfers. There are three general 
categories of bursts: 

Imprecise bursts 

Request information is given for each transfer. Length information may 
change during the burst. 

Precise bursts 

Request information is given for each transfer, but length information is 
constant throughout the burst. 

Single request / multiple data bursts (also known as packets) 

Also a precise burst, but request information is given only once for the 
entire burst 

To express bursts on the OCP interface, at least the address sequence and 
length of the burst must be communicated, either directly using the 
MBurstSeq and MBurstLength signals, or indirectly through an explicit 
constant tie-off as described in "Signal Mismatch Tie-off Rules" on page 53. 

A single (non-burst) request on an OCP interface with burst support is 
encoded as a request with any legal burst address sequence and a burst 
length of 1. 

The ReadEx, ReadLinked, and WriteConditional commands can not be used 
as part of a burst. The unlocking Write or WriteNonPost command associated 
with a ReadEx command also can not be used as part of a burst 

Burst Address Sequence 

The relationship of the MBurstSeq encodings and corresponding address 
sequences are shown in Table 18. The table also indicates whether a burst 
sequence type is packing or not, a concept discussed on page 43* 



Table W 


Burst Address Sequences 




Mnemonic 


Name Address Sequence 


Packing 


DFLT1 


custom (packed) user-specified 


yes 


DFLT2 


custom (not packed) user-specified 


no 


1NCR 


Incrementing Incremented by OCP word size 
each transfer* 


yes 


STRM 


streaming constant each transfer 


no 
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Mnemonic 


Name 


Address Sequence 


Packing 


UNKN 


unknown 


none specified 


Implementation 


WRAP 


wrapping 


like 1NCR, except wrap at 
address boundary aligned with 
MBurstLength * OCP word size 


yes 



XOR exclusive OR see below for precise definition yes 

•Bursts must not wrap around the OCP address size. 



The address sequence for exclusive OR bursts is as follows. Let BASE be the 
lowest byte address in the burst, which must be aligned with the total burst 
size. Let F1RSTJDFFSET be the byte offset (from BASE) of the first transfer in 
the burst. Let CURRENT_COUNT be the count of the current transfer In the 
burst, starting at 0. Let WORD.SHIFT be the log2 of the OCP word size in 
bytes. Then the current address of the transfer is BASE | (F1RST.OFFSET A 
(CURRENT.COUNT « WORD.SHIFT)). 

Burst address sequence UNKN is used when the address sequence Is not stat- 
ically known for the burst In contrast, DFLT1 and DFLT2 address sequences 
are known, but are core or system specific. 

Burst address sequences WRAP and XOR can only be used for precise bursts 
with a power- of- two burst length. 

Not all masters and slaves need to support all burst sequences. A separate 
protocol parameter described in "Optional Burst Sequences" on page 47 is 
provided for each burst sequence to indicate support for that burst sequence. 

Byte Enable Restrictions 

Burst address sequences STRM and DFLT2 must have at least one byte 
enable asserted for each transfer In the burst Bursts with the STRM address 
sequence must have the same byte enable pattern for each transfer in the 
burst. 

Packing 

Packing allows the system to make use of the burst attributes to improve the 
overall data transfer efficiency in the face of multiple OCP interfaces of 
different data widths. For example, if a bridge is translatinjg a narrow OCP to 
a wide OCP, it can aggregate (or pack) the incoming narrow transfers into a 
smaller number of outgoing wide transfers. Burst address sequences are clas- 
sified as either packing, or not packing. 

For burst address sequences that are packing, the conversion between 
different OCP data widths is achieved through aggregation or splitting. 
Narrow OCP words are collected together to form a wide OCP word. A wide 
OCP word is split into several narrow OCP words. The byte-speciflc portion of 
MDatalnfo and SDatalnfo is aggregated or split with the data. The transfer- 
specific portion of MDatalnfo and SDatalnfo is unaffected. The packing and 
unpacking order depends on endianness as described on page 41. 
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For burst address sequences that are not packing, conversion between 
different OCP data widths Is achieved using padding and stripping. A narrow 
OCP word is padded to form a wide OCP word with only the relevant byte 
enables turned on, A wide OCP word is stripped to form a narrow OCP word. 
The byte-speciflc portion of MDatalnfo and SDatalnfo is zero-padded or 
stripped with the data. The transfer- specific portion of MDatalnfo and 
SDatalnfo Is unaffected. Width conversion can be performed reliably only if 
the wide OCP interface has byte enables associated with it For wide to narrow 
conversion the byte enables are restricted to a subset that can be expressed 
within a single word of the narrow OCP interface. 

Since the address sequence of DFLT1 is user- specified, the behavior of DFLT1 
bursts through data width conversion is implementation- specific. 

Burst Length, Precise and Imprecise Bursts 

The MBurstLength field Indicates the number of transfers in the buret 

Precise bursts (MBurstPrecise set to 1) 

MBurstLength must be held constant throughout the burst, so the exact 
burst length can be obtained from the first transfer, A precise burst is 
completed by the transfer of the correct number of OCP words. Precise 
bursts are recommended over imprecise bursts because they allow for 
increased hardware optimization. 

Imprecise bursts (MBurstPrecise set to 0} 

MBurstLength can change throughout the burst, and indicates the 
current best guess of the number of transfers left in the burst {Including 
the current one). An imprecise burst is completed by an MBurstLength of 



Constant Fields in Bursts 

MCmd. MAddrSpace, MConnlD, MBurstPrecise, MBurstSingleReq, 
MBurstSeq, MAtomicLength, and MReqlnfo must all be held steady by the 
master for every transfer In a burst, regardless of whether the burst Is precise 
or imprecise. Similarly, SRespInfo must be held steady by the slave for every 
transfer in a burst 



Atomicity 

When interleaving requests from different initiators on the way to or at the 
target, the master uses MAtomicLength to indicate the number of OCP words 
within a burst that must be kept together as an atomic quantity. If MAtomi- 
cLength is greater than the actual length of the burst, the atomicity 
requirement ends with the end of the burst Specifying atomicity require- 
ments explicitly Is especially useful when multiple OCP interfaces are involved 
that have different data widths. 

For master cores. It Is best to make the atomic size as small as required and. 
If possible, to keep the groups of atomic words address-aligned with the group 
size. 



OCP-IP Confidential 



Protocol Semantics 45 



Single Request / Multiple Data Bursts (Packets) 

MBurstSIngleReq specifies whether a burst can be communicated using a 
single request / multiple data protocol. When MBurstSIngleReq is 0, each 
request has a single data word associated with it When MBurstSIngleReq is 
1, each request may have multiple data words associated with it according to 
the value of MBurstLength. MBurstSIngleReq may be set to 1 only if MBurst- 
Precise Is set to 1. In addition, if any write-type commands are enabled, 
datahandshake must be set to 1. 

When MBurstSIngleReq is set to 1, write type transfers have MBurstLength 
phases and a single response phase {if writeresp_enable=l) per request 
while read- type transfers have MBurstLength response phases per request as 
shown in Table 17 on page 35. 

For write type transfers when MBurstSIngleReq Is set to 1 and the MDataBy- 
teEn field is present, that field in each data transfer phase specifies the partial 
word pattern for the phase. When MBurstSIngleReq Is set to 1 and the 
MDataByteEn field Is not present the MByteEn pattern of the request phase 
applies to all data transfer phases. 

For read type transfers when MBurstSIngleReq Is set to 1, the MByteEn field 
specifies the byte enable pattern that is applied to all data transfers in the 
burst 



MReqLast, MDataLast, SRespLast 

Optional signals MReqLast. MDataLast and SRespLast provide redundant 
information that Indicates the last request datahandshake, and response 
phase In a burst respectively. These signals are provided as a convenience to 
the recipient of the signal. To avoid separate counting mechanisms to track 
bursts, cores that have the information available Internally are encouraged to 
provide it at the OCP interface. 

MReqLast Is 0 for all request phases in a burst except the last one. MReqLast 
is 1 for the last request phase in a burst, for single request / multiple data 
bursts, and for single requests. 

MDataLast Is 0 for all datahandshake phases in a burst except the last one. 
MDataLast is 1 for the last datahandshake phase in a burst and for the only 
datahandshake phase of a single request 

SRespLast is 0 for all response phases in a burst except the last one. SRes- 
pLast is 1 for the last response phase in a burst, for the response to a write- 
type single request / multiple data burst, and for the response to a single 
request 
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Threads and Connections 

AD transfers within a single thread must remain ordered. (See "Phase 
Ordering Between Transfers* on page 36.) 

Using multiple threads, it is possible to support concurrent activity, and out- 
of-order completion of transfers. All transfers within a given thread must 
remain strictly ordered, but there are no ordering rules for transfers that are 
in different threads. Mapping of individual requests and responses to threads 
is handled through the MlTireadlD and SThreadID fields respectively. If 
datahandshake has been enabled when multiple threads are present, there 
must also be an MDataThreadlD field to annotate the datahandshake phase. 
If datahandshake is set to 1 and sdatathreadbusy Is set to 0, the order of 
datahandshake phases must follow the order of request phases across all 
threads. If sdatathreadbusy is set to 1 ( the request order and datahand- 
shake order are Independent across threads. 

The use of thread IDs allows two entities that are communicating over an OCP 
Interface to assign transfers to particular threads. If one of the communi- 
cating entitles is Itself a bridge to another OCP Interface, the information 
about which transfers are part of which thread must be maintained by the 
bridge, but the actual assignment of thread IDs Is done on a per-OCP-inter- 
face basis. There is no way for a slave on the far side of a bridge to extract the 
original thread ID unless the slave design comprehends the characteristics of 
the bridge. 

Use connections whenever source thread Information about a request must 
be sent end-to-end from master to slave. Any bridges in the path between the 
end-to-end partners preserve the connection ID, even as thread IDs are re- 
assigned on each OCP interface In the path. The MConnID field transfers the 
connection ID during the request phase. Since this establishes the mapping 
onto a thread ID, the other phases do not require a connection ID but are 
unambiguous with only a thread ID. 

The SThreadBusy, SDataThreadbusy, and MThreadBusy signals are used to 
indicate that a particular thread is busy. The protocol parameters 
sthreadbusy_exact, sdatathreadbusy_exact, and mthreadbusy_exact 
can be used to force precise semantics for these signals and assure that a 
multi-threaded OCP Interface never blocks. For more information, see 
"Ungrouped Signals" on page 36. 
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OCP Configuration 

This section describes configuration options that control interface 
capabilities. 

Protocol Options 

Optional Commands 

Not all devices support all commands. Each command in Table 19 has an 
enabling parameter to indicate if that command is supported. 



Table 1 9 Command Enabling Parameters 



Command 


Parameter 


Broadcast 


broodcast.enoble 


Read 


read.enable 


ReadEx 


readex.enabie 


ReadUnked and 


rdlwrc_enable 


WriteConditlonal 




Write 


wrlte_enab(e 


WriteNonPost 


writenonposLen able 



The following conditions apply to command support: 

• A master with one of these options set to 0 must not generate the 
corresponding command* 

• A slave with one of these options set to 0 cannot service the corresponding 
command, 

• At least one of the command enables must be set to 1. 

• writenonpost_enablecanbesetto 1 only ifwriteresp__enableissetto 
1. 

• rdlwrc_enable can be set to 1 only if writeresp.enable is set to 1. 

• If any read-type command is enabled or writeresp.enable is set to 1, 
resp must be set to 1. 

• If readex_enable is set to 1, write w ena;ble or writenonpost_enable 
must be set to 1. 

Optional Burst Sequences 

Not all masters and slaves need to support all burst address sequences* Table 
20 lists the protocol parameter for each burst sequence. A master that has the 
parameter set to 1 may generate the corresponding burst sequence. A slave 
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that has the parameter set to 1 can service the corresponding burst sequence. 
If MBurstLength Is not tied off to a value of 1, at least one of the burst 
sequence parameters must be enabled. 

Table 20 Burst Sequence Parameters 



Burst Sequence Parameter 



DFLT1 


burst$eq_dfltLenabie 


DFLT2 


bur5t$eq_dfit2_enab!e 


INCR 


burstseqjncr_enabie 


S7RM 


burstseq.strm.enable 


UNKN 


burstsecLunkn.enable 


WRAP 


burstseq_wrap_.enable 


XOR 


burstseq_xor_enable 



For additional information describing bursts, see "Burst Definition" on 
page 42. 

Byte Enable Patterns 

Not all devices support all allowable byte enable patterns. The 

f orce_aligned parameter limits byte enable patterns on MByteEn and 

MDataByteEn to be power- of- two in size and aligned to that size. The byte 

enable pattern of all Os is explicitly Included in the legal f orce_aligned 

patterns. 

• A master with this option set to 1 must not generate any byte enable 
patterns that are not force aligned. 

• A slave with this option set to 1 cannot handle any byte enable patterns 
that are not force aligned. 

f orce__aligned can be set to 1 only when data_wdth Is set to a power-of-two 
value. 

Burst Alignment 

The burst_aligned parameter provides information about the length and 
alignment of INCR bursts issued by a master and can be used to optimize the 
system. Setting burst_aligned to 1 requires all INCR bursts to: 

• Have an exact power-of-two number of transfers 

• Have their starting address aligned with their total burst size 

• Be Issued as precise bursts 
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Exact ThreadBusy 

The sthreadbusy_exact and mthreadbusy_exact parameters require strict 
semantics for the SThreadBusy and MThreadBusy signals to achieve a guar- 
antee that a multi-threaded OCP interface never blocks. See "Ungrouped 
Sfgnal9 w on page 36 for a precise definition of these parameters. The following 
conditions must be true: 

• When sthreadbusy_exact is set to 1, cmdaccept must be set to 0, and 
SCmdAccept is tied off to a value of 1. 

• When sthreadbusy_exact is set to 1, datahandshake is set to 1, and 
sdatathreadbusy is set to 0, dataaccept must be set to 0 and 
SDataAccept is tied off to a value of 1 . 

• When sdatathreadbusy_exact Is set to 1, dataaccept must be set to 0 
and SDataAccept is tied off to a value of 1. 

• When mthreadbusy_exact Is set to 1, respaccept must be set to 0, and 
MRespAccept is tied off to a value of 1. 

The following conditions are illegal because no flow control can be exerted: 

• sthreadbusy_exact is set to 0, cmdaccept is set to 0, but sthreadbusy 
is set to 1. 

• mthreadbusy_exact is set to 0, respaccept is set to 0. but 
mthreadbusy is set to 1. 

Endianness 

The endian parameter specifies the endianness of a core. The behavior of 
each endianness choice is summarized in Table 21. 



Table 21 


Endianness 


Endianness 


Description 


little 


core Is little-endian 


big 


core Is bfg-endian 


both 


core can be either big or little endlaa depending on its static or 




dynamic configuration (e.g. CPUs) 



neutral core has no Inherent endianness (e.g. memories, cores that deal 

only In OCP words) 



As far as OCP is concerned, little endian means that lower addresses are asso- 
ciated with lower numbered data bits (byte lanes), while big endian means 
that higher addresses are associated with lower numbered data bits (byte 
lanes). This becomes significant when packing is concerned. {see "Packing" on 
page 43). In addition, for non-power-of-2 data widths, tie-off padding is 
always added at the most significant end of the OCP word. See "Endianness* 
on page 41 for additional Information. 
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Phase Options 

The datahandshake parameter allows write data to have a handshake Inter- 
face separate from the request group. 

Datahandshake 

If datahandshake Is set to l f the MDataVaiid and SDataAccept signals are 
added to the OCP interface, a separate datahandshake phase is added, and 
the MData and MDatalnfo fields are moved from the request group to the 
datahandshake group. 

Request and Data Together 

While datahandshake Is required for OCP Interfaces that are capable of 
communicating single request / multiple data bursts, a fully separated datah- 
andshake may be overkill for some cores. The parameter reqdata_together 
is used to specify that the request and datahandshake phases of the first 
transfer in a single request / multiple data write- type burst begin and end 
together. 

A master with reqdata_together set to 1 must present the request and first 
write data word In the same cycle and can expect that the slave will accept 
them together. If sthreadbusy_exact and sdatathreadbusy_exact are 
both set to 1 , this implies that a request and first write data can be presented 
only when both SThreadBusy and SDataThreadBusy for the corresponding 
thread are 0. A slave with reqdata_together set to 1 must accept the 
request and first write data word in the same cycle and can expect that they 
will be presented together. 

The parameter reqdata_together can only be set to 1 if burstsinglereq is 
set to I t or burstsinglereg is set to 0 and MBurstSingleReq Is tied off to 1. 

Write Responses 

To configure the OCP to Include response phases for write-type requests, use 
the writeresp_enable parameter. 

• If responses are not enabled on writes (writeresp_enable set to 0), then 
all write commands complete on command acceptance, and the 
WrlteNonPost, WriteConditional, and ReadLlnked commands are not 
allowed. 

♦ If responses are enabled (writeresp_enable set to 1), writes may follow 
either a posted or non-posted model depending on when the response is 
returned. For this case, resp must be set to 1. 

Signal Options 

The configuration parameters described in "Signal Configuration" on page 25, 
not only configure the corresponding signal into the OCP interface, but also 
enable the function. For example, if the burstseq and burstlength param- 
eters are enabled the MBurstSeq and MBurstLength fields are added and the 
interface also supports burst extensions as described In "Burst Definition" on 
page 42. 
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Minimum Implementation 

A minimal OCP implementation must support at least the basic OCP dataflow 
signals. OCP-interoperable masters and slaves must support the command 
type Idle and at least one other command type. 

If the SResp field Is present in the OCP interface, OCP- Interoperable masters 
and slaves must support response types NULL and DVA. The ERR response 
type is optional and should only be included if the OCP-interoperable slave 
has the ability to report errors. All OCP masters must be able to accept the 
ERR response, if rdlwrc_enable is set to 1, the FAIL response type must be 
supported by OCP masters and slaves. 

OCP Interface Interoperability 

Two devices connected together each have their own OCP configuration. The 
two Interfaces are only Interoperable (allowing the two devices to be connected 
together and communicate using the OCP protocol semantics) If they are 
interoperable at the core, protocol, phase, and signal levels. 

1. At the core level: 

• One interface must act as master and the other as slave. 

• If system signals are present one interface must act as core and the 
other as system. 

2. At the protocol level, the following conditions determine interface 
interoperability: 

• If the slave has read_enable set to 0, the master must have 
read_enable set to 0, or it must not Issue Read commands. 

• If the slave has readex_enable set to 0, the master must have 
readex_enable set to 0, or it must not Issue ReadEx commands. 

• If the slave has rdlwrc_enable set to 0, the master must have 
rdlwrc_enable set to 0, or it must not issue either ReadLlnked or 
WriteConditional commands. 

• If the slave has wri te_enable set to 0 f the master must have 
write_enable set to 0, or it must not issue Write commands. 

• If the slave has writenonpost_enable set to 0. the master must have 
writenonpost_enable set to 0, or it must not Issue WriteNonPost 
commands. 

• If the slave has broadcast_enable set to 0, the master must have 
broadcast_enable set to 0, or it must not Issue Broadcast 
commands. 

• If the slave has burs tseqL.incr_enable set to 0, the master must 
have burstseq_incr_enable set to 0, or it must not Issue INCR 
bursts. 



OCP-IP Confidential 



52 Open Core Protocol Specification 



• If the slave has burstseq_strnuenable set to 0, the master must 
have burstseq_stm\_enable set to 0, or It must not issue STRM 
bursts. 

• If the slave has burstseq_df 1 tl__enable set to 0, the master must 
have burstseq„df ltl_enable set to 0, or it must not issue DFLT1 
bursts. 

• If the slave has burstseq_df lt2_enable set to 0« the master must 
have burstseq_df lt2_enable set to 0, or It must not issue DFLT2 
bursts, 

• If the slave has burs tseq_wrap_enable set to 0, the master must 
have burstseq_wrap_enable set to 0, or It must not issue WRAP 
bursts. 

• If the slave has bursts eq_xor_enabl e set to 0, the master must have 
burstseq_xor_enable set to 0, or It must not issue XOR bursts. 

• If the slave has burstseq_unkn_enable set to 0, the master must 
have burstseq_unkn_enable set to 0, or it must not issue UNKN 
bursts, 

• If the slave has f orce__aligned, the master has f orce_aligned or it 
must limit itself to aligned byte enable patterns. 

• Configuration of the mdatabyteen parameter Is Identical between 
master and slave, 

• If the slave has burs t_aligned, the master has burst_aligned or it 
must limit itself to issue all 1NCR burst using burst_aligned rules. 

• If the Interface includes SThreadBusy, the sthreadbusy_exact 
parameter Is identical between master and slave. 

• If the interface Includes MThreadBusy, the mthreadbusy_exact 
parameter Is identical between master and slave. 

• If the interface includes SDataThreadBusy, the 
sdatathreadbusy_exact parameter is identical between master and 
slave. 

• All combinations of the endian parameter between master and slave 
are Interoperable as far as the OCP interface is concerned. There may 
be core-specific Issues if the endianness is mismatched. 

3. At the phase level the two Interfaces are interoperable if: 

• Configuration of the datahandshake parameter Is Identical between 
master and slave. 

• Configuration of the wri teresp_enable parameter Is Identical 
between master and slave. 

• Configuration of the reqdat altogether parameter is identical 
between master and slave. 

4. At the signal level, two Interfaces are Interoperable if; 



OCP-IP Confidential 



Protocol Semantics 53 



• data_wdth Is identical for master and slave, or if one or both 
data_wdth configurations are not a pcwer-of-two, if that data_wdth 
rounded up to the next power-of-two is Identical for master and slave* 

• The master and slave both have mreset or sreset set to 1. 

• If the master has mreset set to 1, the slave has mreset set to 1. 

• If the slave has sreset is set to 1, the master has sreset set to 1. 

• The tie-off rules, described In the next section are observed for any 
mismatch at the signal level for fields other than MData and SData. 

Signal Mismatch Tie-off Rules 

Width mismatch for all fields other than MData and SData is handled through 
a set of signal tie-off rules. The rules state whether a master and slave that 
are mismatched in a particular field width configuration are interoperable, 
and if so how they must be connected together by tying off the mismatched 
signals. 

If there Is a width mismatch between master and slave for a particular signal 
configuration the following rules apply: 

• If there are more outputs than inputs (the driver of the field has a wider 
configuration than the receiver of the field) the low-order output bits are 
connected to the input bits, and the high-order output bits are lost The 
Interfaces are Interoperable if the sender of the field explicitly limits Itself 
to encodings that only make use of the bits that are within the 
configuration of the receiver of the field. 

• If there are more inputs than outputs (the driver of field has a narrower 
configuration than the receiver of the field) the low-order Input bits are 
connected to the output bits, and the high-order input bits are tied to 
logical 0. The interfaces are always interoperable, but only a portion of the 
legal encodings are used on that field. 

If one of the cores has a signal configured and the other does not, the following 
rules apply: 

• If the core that would be the driver of the field does not have the field 
configured, the Input Is tied off to the constant specified In the driving 
core's configuration, or if no constant tie-off Is specified, to the default tie* 
off constant (see Table 12 on page 25). The Interfaces are interoperable tf 
the encodings supported by the receiver's configuration of the field 
Include the tie-off constant. 

• If the core that would be the receiver of the field does not have the field 
configured, the output Is lost. The receiver of the signal must behave as 
though in every phase it were receiving the tie-off constant specified in Its 
configuration, or if no constant tie-off is specified, the default tie-off 
constant (see Table 12 on page 25). The interfaces are interoperable if the 
driver of the signal can limit itself to only driving the tie-off constant of the 
receiver. 



OCP-IP Confidential 



54 Open Core Protocol Specification 



If neither core has a signal configured, the interfaces are Interoperable If both 
cores have the same tie-off constant, where the tie-off constant is either 
explicitly specified, or If no constant tie-off is specified explicitly, is the default 
tie-off (see Table 12 on page 25). 

While the tie-off rules allow two mismatched cores to be connected to one 
another, this may not be enough to guarantee meaningful communication, 
especially when core-specific encodings are used for signals such as 
MReqlnfo. 

As the previous rules suggest, specifying core specific tie-off constants that 
are different than the default tie-offs for a signal {see Table 12 on page 25) 
makes It less likely that the core will be interoperable with other cores. 

Configuration Parameter Defaults 

To assure OCP interface Interoperability between a master and a slave 
requires complete knowledge of the OCP interface configuration of both 
master and slave. This Is achieved by a combination of (a) requiring some 
parameters to be explicitly specified for each core, and (b) defining defaults 
that are used when a parameter is not explicitly specified for a core. 

Table 22 lists all configuration parameters. For parameters that do not need 
to be specified, a default value is listed, which Is used whenever an explicit 
parameter value Is not specified. Certain parameters are always required in 
certain configurations, and for these no default is specified. 

Table 22 Configuration Parameter Defaults 

Type Parameter Default 

Protocol broodcasLenoble 0 



bureLaligned 


0 


bur$tsecLdfltl_enable 


0 


bur5tseq_dflt2_enable 


0 


burstseqjncr_enable 


1 


burstsecLstrm^enable 


0 


burstseq_unkn_enable 


0 


bur$tseq_wrap_enable 


0 


burstseq_xor_enable 


0 


endlan 


little 


force_allgned 


0 


mthreadbusy.exact 


0 


rdlwrc.enable 


0 
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Type 


Parameter 


Default 




read.enable 


1 




readex_enab!e 


0 




sdatathreadbusy.exact 


0 




sthreadbusy.exact 


0 




write_enable 


1 




writenonpost_enab!e 


0 


Phase 


datahandshake 


0 




reqdatajogether 


0 




wrJferesp_enable 


0 


signal 


addf 


1 


(Dataflow) 


addr_wdtn 


No default - must be explicitly specified if 
addr is set to 1 




addrspace 


0 




addrspace_wdth 


No default - must be explicitly specified If 
addrspace Is set to 1 




atomlclength 


0 




atomlc!ength_wdth 


No default - must be explicitly specified tf 
atomlclength is set to 1 




bursflength 


0 




burstlength_wdth 


No default * must be explicitly specified If 
bursflength Is set to 1 




burstpreclse 


0 




burstseq 


0 




burstsinglereq 


0 




byteen 


0 




crndaccept 


1 




connid 


0 




connld_wdth 


No default - must be explicitly specified If 
connld is set to 1 




dataaccept 


0 




datalast 


0 




data.wdth 


No default - must be explicitly specified If 
mdota or sdcrta Is set to 1 




mdata 


1 




mdatabyteen 


0 




mdatainfo 


0 
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Type 

Signal 
(Dataflow) 



Parameter 


Default 


mdataInfo_wdth 
mdatalnfobyte.wdth 


No default * must be explicitly specified if 
mdatalnfo Is set to 1 


mthreadbusy 


0 


reqinfo 


0 


;eqlnfo_wdth 


No default - must be explicitly specified If 
reqinfo is set to 1 


reqfast 


0 


resp 


1 


respaccept 


0 


respinfo 


0 


resplnfo.wdth 


No default - must be explicitly specified If 
respinfo Is set to 1 


resplast 


0 


sdata 


1 


sdatainfo 


0 


* • ♦ # ill 

sdatainfo_wdth 
sdatalnfobyte.wdth 


No default - must be explicitly specified If 
sdatainfo Is set to 1 


sdatathreodbusy 


0 


sthreadbusy 


0 


threads 


1 
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Type Parameter Default 

Signal control 0 



Signal 
(Test) 



controlbusy 


0 


controLwdth 


No default - must be explicitly specified If 
control Is set to 1 


controlwr 


0 


Interrupt 


0 


merror 


0 


mflag 


0 


mflag.v/dth 


No default - must be explicitly specified if 
mflag Is set to 1 


mreset 


No default - must be explicitly specified 


serror 


0 


sflag 


0 


sflag_wdth 


No default - must be explicitly specified If 
sflag Is set to 1 


sreset 


No default - must be explicitly specified 


status 


0 


statusbusy 


0 


statusrd 


0 


status.wdth 


No default - must be explicitly specified If 
status Is set to 1 


clkctri_enable 


0 


jtag_enable 


0 


jtagtrsLenable 


0 


scanctrLwdth 


0 


scanport 


0 


sconport.wdth 


No default - must be explicitly specified If 
scanport Is set to 1 
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The interface configuration file describes a group of signals, called a bundle. 
For OCP interfaces, the bundle is pre-defined, and no Interface configuration 
file is required. If you are using an interface other than OCP in your core RTL 
configuration fUe, the interface configuration file is required. 

Name the file <bundle-name>_intfc.conf where bundle- name is the name 
given to the bundle that is being defined in the file. 



Lexical Grammar 

The lexical conventions used In the Interface configuration file are: 

<name> : (<!etter> | '_') (<letter> | | <diglt>)' 
<letter> : 'a* .. 'z' | TV 'Z 
<digJt> : XT .. '9' 

<number> : <lntegen> | <float> 

<lnteger> : <diglt>+ 

<float> : <mantlssa> t<exponent>l 

<mantlssa>: (<integer> \*) |(7 <lnteger>) |{<lnteger> 7 <lnteger>) 
<exponent>: ('e' | 'E*) (V | '-'J <lnteger> 
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Syntax 

The Interface configuration (lie is written using standard Tel syntax. Syntax 
is described using the following conventions: 

I ] optional construct 

| or, alternate constructs 

* zero or more repetitions 
+ one or more repetitions 

< > enclose names of syntactic units 
( } are used for grouping 

I ) are part of the format and are required. An open brace must always 
appear on the same line as the statement 

# comments 

The syntax of the Interface configuration file is: 

version <version_string> 

bundle <bundle_name> {<bundle_stmt>+} 

where: 

<bundle_stmt>: 

j bundle_version <version_string> 

| interface_types <interface_type-name>+ 

| net <net_name> {<net_stmt>*} 

| proprietary <vendor_code> <organization_name> 
{ <pr opr i e t ary_s tat emen t s > } 
<net_stmt>: 

j direction (input (output |inout)+ 

| width <number-of-bits> 

| vhdl_type <type-string> 

j type <net-type> 

| proprietary <vendor_code> <organization_name> 
{ <proprietary_s tat ements> } 



The file must contain a single version statement followed by a single bundle 
statement The bundle statement must contain exactly one interfacejypes 
statement, and one or more net statements. Each net statement must contain 
exactly one direction statement and may contain additional statements of 
other types. 

version 

The version statement identifies the version of the Interface configuration 
file format. The version string consists of major and minor version 
numbers separated by a decimal. The current version is 2.5. 

bundle 

This statement is required and indicates that a bundle is being defined 
instead of a core or a chip. Make the bundle-name the same name as the 
one used In the file name. 
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bundle.version 

If there are multiple versions use the bundle_version statement to Identify 
the version of the bundle. The version string consists of major and minor 
version numbers separated by a decimal. If no bundIe_vers!on statement 
is present, the default version 1.0 Is used. The current bundle version of 
OCP is 2.0. 

interface_types 

The interface Jypes statement lists the legal values for the Interface types 
associated with the bundle. Interface types are used by the toolset in 
conjunction with the direction statement to determine whether an 
interface uses a net as an input or output signal. This statement is 
required and must have at least one type defined. 

Predefined interface types for OCP bundles are slave, master, 
system.slave, system_master, and monitor. These are explained in 
Table 14 on page 28. 

net 

The net statement defines the signals that comprise the bundle. There 
should be one net statement for each signal that Is part of the bundle. A 
net can also represent a bus of signals. In this case the net width is 
specified using the width statement. If no width statement Is provided, the 
net width defaults to one. A bundle is required to contain at least one net. 
The net-name field is the same as the one used in the net-name field of 
the port statements In the core rtl file described in Chapter 6. 

proprietaiy 

For a description, see "Proprietaiy Statement" on page 73. 
direction 

The direction statement Indicates whether the net Is an input, output, or 
inout This field is required and must have as many direction-values as 
there are Interface types. Hie order of the values must duplicate the order 
of the Interface types In the interface_types statement The legal values are 
input output, and inout 

vhdLiype 

By default VHDL signals and ports are assumed to be stdjoglc and 
stdjogicjvector, but if you have ports on a core that are of a different type, 
the vhdl_type command can be used on a net This type will be used only 
when soccomp is run with the design_top=vhdl option to produce a 
VHDL top-level netlist 

type 

The type statement specifies that a net has special handling needs for 
downstream tools such as synthesis and layout Table 23 shows the 
allowed <net-type> options. If no <net-type> is specified, normal is 
assumed. 
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Table 23 net-type Options 



<net-typc> Description 



normal 

clock 

reset 

scanjn 

scan_out 

scaruenable 

testjnode 

Jtagjck 

jtagjdl 

Jtogjdo 

Jtagjms 

jtagjrstn 



default for nets without special handling needs 
clock net 
reset net 
scan Input net 
scan output net 

scan enable net. serves as mode control between functional and 
scan data Inputs 

test mode net puts logic into a special mode for use during 
production testing 

JTAG test clock 

JTAG test data In 

JTAG test data out 

JTAG test mode select 

JTAG test logic reset 



proprietary 

For a description, see Troprietaiy Statement* on page 73. 

The following example defines an SRAM Interface. The bundle being defined 
is called s ram 16. 

bundle "sramlS" { 

# Two interface types are defined, one is labeled 

# "controller" and the other is labeled "memory 11 
interface_types controller memory 

# A net named Address is defined to be part of this bundle, 
net "Address" { 

# The direction of the "Address" net is defined to be 

# "output 0 for interfaces of type "controller" and "input" 

# for interfaces of type "memory", 
direction output input 

# The width statement indicates that there are 14 bits in 

# the "Address" net. 
width 14 

} 

net "WData" { 

direction output input 
width 16 

} 

net "RData" { 

# The direction of the "RData" net is defined to be 
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# a input" for bundle of type 9 controller" and "output" for 

# bundles of type "memory", 
direction input output 
width 16 

} 

net fl We_n n { 

direction output input 

} 

net fl Oe_n M { 

direction output input 

} 

net "Reset" { 

direction output input 
type reset 

} 

# close the bundle 
} 
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The required core RTL configuration flle provides a description of the core and 
its interfaces. The name of the flle needs to be <corename>_rtI.conf t where 
corename is the name of the module to be used. For example, the file defining 
a core named uart must be called uart_rtLconf. 

For a description of the lexical grammar, see page 59. 



Syntax 



The core RTL configuration file is written using standard Tel syntax. Syntax 
is described using the following conventions: 

I ) optional construct 

| or t alternate constructs 

* zero or more repetitions 
+ one or more repetitions 

<> enclose names of syntactic units 
0 are used for grouping 

I } are part of the format and are required. An open brace must always 
appear on the same line as the statement 

# comments 

The syntax for the core KTL configuration flle is: 

version <version_string> 

module <core_name> {<core_stmt> + } 

core_name is the name of the core being described and: 

<core_stmt>: 

| icon <file_name> 

I core_id <vendor_code> <core_code> <revision_code> 
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[<description>] 
| interface <interface_name> bundle <bundle_name> 

[ {<interf acejx>dy>* } ] 
j addr_region <name> {<addr_regionJx>dy>*} 
| proprietary <vendor_code> <organization_name> 
{<proprietary_statements>} 

The file must contain a single version statement followed by a single module 
statement. The module statement contains multiple core statements. One 
corejd must be included. At least one interface statement must be included. 
One Icon statement and one or more addr_reg!on and proprietary statements 
may also be included. 



Components 

This section describes the core RTL configuration file components. 

Version Statement 

The version statement identifies the version of the core RTL configuration file 
format. The version string consists of major and minor version numbers 
separated by a period. The current version of the file is 2.5. 

Icon Statement 

This statement specifies the Icon to display on a core. The syntax Is: 
icon <file_name> 

filename is the name of the graphic file, without any directory names. Store 
the file in the design directory of the core. For example: 

icon ,, myCore.ppm ,, 

The supported graphic formats are GIF, PPM, and PGM. Graphics should be 
no larger than 80x80 pixels. Since the text used for the core is white, use a 
dark background for your Icon, otherwise it will be difficult to read. 

Corejd Statement 

The corejd statement provides identifying information to the tools about the 
core. This Information Is required. Syntax of the corejd statement is: 

core_id <vendor__code> <core_code> <revision_code> [<description>] 
where: 

vendor.code An OCP-1P- assigned vendor code that uniquely Identifies the 
core developer. OCP-IP maintains a registry of assigned 
vendor codes. The allowed range is 0x0000 - OxFFFF. Use 
0x5555 to denote an anonymous vendor. For a list of codes 
check www.ocpip.org. 
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core.code A developer-assigned core code that (in combination with the 
vendor code) uniquely Identifies the core. OCP-IP provides 
suggested values for common cores. Refer to "Defined Core 
Code Values". The allowed range is 0x000 - OxFFR 

revJslon_code A developer-assigned revision code that can provide core 
revision information. The allowed range is 0x0 - OxR 

description An optional Tel string that provides a short description of the 
core. 

Defined Core Code Values 

0x000 - 0x7FF: Pre-defined 
0x000 - OxOFF: Memory 
Sum values from following choices: 
ROM: 

0x0: None 

0x1: ROM/EPROM 

0x2: Flash (writable) 

0x3: Reserved 

SRAM: 

0x0: None 

0x4: Non-pipelined SRAM 
0x8: Pipelined SRAM 
OxC: Reserved 
DRAM: 

0x00: None 

0x10: DRAM (trad., page mode, EDO, etc.) 

0x20: SDRAM (all flavors) 

0x30: RDRAM (all flavors) 

0x40: Several 

0x50: Reserved 

0x60: Reserved 

0x70: Reserved 

Built-in DMA: 

0x00: No 

0x80: Yes 

Values from 0x000 - OxOFF are defined/reserved 
Example: Memory controller supporting only SDRAM & Flash 
. would have <cc> = 0x2 + 0x20 = 0x022 

0x100 - OxlFF: General -purpose processors 
Sum values from following choices plus offset 0x100: 
Word size: 
0x0: 8 -bit 
0x1: 16-bit 
0x2: 32-bit 
0x3: 64 -bit 
0x4 - 0x7: Reserved 
Embedded cache: 
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0x0: No cache 

0x8: Cache (Instruction, Data, combined, or both) 

Processor Type: 

0x00: CPU 

0x10: DSP 

0x20: Hybrid 

0x30: Reserved 
Only values from 0x100 - 0xl3F are defined/reserved 
Example: 32-bit CPU with embedded cache 

would have <cc> = 0x100 + 0x2 + 0x8 + 0x00 = OxlOA 

0x200 » 0x2FF: Bridges 

Sum values from following choices plus offset 0x200: 
Domain: 

0x00 - 0x7F: Computing 

0x00 - 0x3F: PC'S 

0x00: ISA (inc. EISA) 

0x01 - OxOF: Reserved 

0x10: PCI <33MHz/32b) 

0x11: PCI (66MHz/32b) 

0x12: PCI (33MHz/64b) 

0x13: PCI (66KHz/64b) 

0x14 - OxlF: AGP, etc. 

0x40 - 0x7F: Reserved 
0x80 - OxBF: Telecom 

OxAO - OxAF: ATM 

OxAO: Utopia Level 1 

OxAl: Utopia Level 2 

OxCO - OxFF: Datacom 
0x300 - 0x3FF: Reserved 
0x400 - 0x5FF: Other processors 

(enumerate types: MPEG audio, MPEG video, 2D Graphics, 
3D Graphics, packet, cell, QAM, Vitterbi, Huffman, 
QPSK, etc J 

0x600 - 0x7 FF: I/O 

(enumerate types: Serial UART, Parallel, keyboard, mouse, 
gameport, USB, 1394, Ethernet 10/100/1000, ATM PHY, 
NTSC, audio in/out, A/D, D/A, I2C, PCI, AGP, ISA, 
etc.) 

0x800 - OxFFF: Vendor-defined 

(explicitly left up to vendor) 
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Interface Statement 

The Interface statement defines and names the Interfaces of a core. The inter- 
face name is required so that cores with multiple interfaces can specify to 
which interface a particular connection should be made. Syntax for the inter- 
face statement Is: 

interface <interface_name> bundle <bundle_name> 
[ {<interf ace_body> + } } 

An interface statement must contain a single Lnterface_type statement and at 
least one port statement All other Interface body statements are optional 

The <bundle_name> must be a defined bundle such as OCP or a bundle spec- 
ified in an interface configuration file as described on page 59. 

In the following example, an interface named xyz is defined as an OCP bundle. 
The quotation marks around xyz are not required but help to distinguish the 
format 

interface "xyz* bundle ocp 

<interf ace_body> : 

| bundle_version <version_string> 

j interface_type <type_name> 

J port <port_name> net <net_name> 

| reference_port <interface_name>.<port_name> net <net_name> 
| prefix <name> 

j param <name> <value> [{ (<attribute> <value>)*}] 
| subnet <net_n&me> <bit_range> <subnet_name> 
j location (n|e|w|s|) <number> 
J proprietary <vendor_code> <organization_name> 
{<proprietary_staten\ents>} 

<bit_range>: 

| <bit_number>(:<bit_number>] 

Ports on a core interface may have names that are different than the nets 
defined in the bundle type for the interface. In this case, each port in the inter- 
face must be mapped to the.net in the bundle with which it is associated. 
Mapping links the module port <prefbo<port_name> with the bundle 
<net_name>. 

The default rules for mapping are that the porLname is the same as the 
net_name and the prefix is the name of the interface. These rules can be over- 
ridden using the Port and Prefix statements, 

Bundle_version Statement 

Where more than one revision exists* the bundle_version statement defines 
the version of the bundle to use. Syntax for the bundle.version statement is: 

bundle_version <version_string> 
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The verslon_strLng consists of major and minor version numbers separated by 
a period. If no bundle_version statement is present, the default version 1.0 is 
used. The current version of the OCP bundle is 2.0. 

Interface Jype Statement 

The interface Jype statement defines characteristics of the bundle. Typically, 
the different types specify whether the core drives or receives a particular 
signal within the bundle. Syntax for the interface_type statement is: 

interface_type <type_jiame> 

The type_name must be a type defined in the bundle definition. If the bundle 
is OCP, the allowed types are: master, system.master, slave, system_slave, 
and monitor as described in Table 14 on page 28. To define a type, specify it 
in the interface configuration file (described on page 59), 

Port Statement 

Use the port statement to map a single port corresponding to a signal that Is 
defined in the bundle. Syntax for the port statement is: 

port <port_name> net <net_name> 

The module port named <prefix><port name> implements the <net_name> 
function of the bundle. The legal net_name values are defined in the bundle 
definition. For OCP bundles, the net names are defined In "Signals and 
Encoding" on page 11. 

Reference_port Statement 

The reference^port statement re-directs a net to another bundle. Syntax for 
the port statement Is: 

reference__port <interface_name>.<port_name> net <net_name> 

The interface (in which the reference_port is declared) does not have the refer- 
ence port and the bundle does not have the reference net. The reference_port 
statement declares that the net Is Internally connected to the given port of the 
referenced interface. For example, consider the following two interfaces: 

interface tp bundle ocp { 

reference _port ip.Clk._i net Clk 
reference_jport ip.SReset_ni net MReset_n 
port ControlJL net Control 
port MCmd_i net MCmd 

} 

interface ip bundle ocp { 
port Clk_i net Clk 
port SReset_ni net SReset_n 
port Control_i net Control 
port MCmd_o net MCmd 
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Figure 7 Reference Port 




OCP bundle OCP bundle 



Figure 7 illustrates the operation of a reference port In the interface tp, no 
ports exist for bundle signals Clk and MReset_n. Neither do the bundle 
signals themselves exist Instead, they reference the corresponding ports in 
the ip interface and nets in the bundle connected to that interface. The 
internal signals in the tp interface that would have been connected to the Clk 
and MReseOi signals of the OCP bundle connected to the tp interface are 
instead connected to the referenced ports in the ip interface. 

Prefix Command 

The prefix command applies to all ports in an interface. It supplies a string 
that serves as the prefix for all core port names in the interface. Syntax for the 
prefix command is: 

prefix <name> 

For example, the statement prefix external, specifies that the names for all 
ports in the Interface are of the form external.*. 

If the prefix command is omitted, the Interface name will be Inserted as the 
default prefix. To omit the prefix from the port name, specify it as an empty 
string, that is prefix ■ • . 

Configurable Interfaces Parameters 

For configurable interfaces, parameters specify configurations. The specific 
parameters for OCP are described in Chapters 3 and 4 and summarized in 
Table 22 on page 54. The syntax for setting a parameter is: 

param <name> <value> [ { (<attribute> <value>)*}] 
<value>: <number> J <name> 
<attribute>: tie_off| width 

If the parameter is used to configure a signal, the attribute list can be used to 
attach additional values to that signal. The supported attributes are the tie- 
off [if the signal is configured out of the interface) and the signal width (if the 
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signal Is configured into the Interface). Specifying the signal width using an 
attribute attached to the signal parameter is equivalent to using the corre- 
sponding signal width parameter but the attribute syntax Is preferred. 

For example, an OCP might be configured to Include an intenrupt signal as 
follows. 

param interrupt 1 

The following example shows the MBurstLength field tied off to a constant 
value of 4. 

param burstlength 0 {tie_off 4} 

The following code shows two equivalent ways of setting the address width to 
16 bits though the second method is preferred. 

param addrjvdth 16 
param addr 1 {width 16} 

Subnet Statement 

The subnet statement assigns names to bits or contiguous bit-fields within a 
net Syntax for the subnet statement is: 

subnet <net_name> <bit_range__list> <subnet_name> 
<bit_range_list> : <bit_range> [ , <bit_range>] * 
<bit_range> : <bit_number> [ : <bit_number>] 

The subnet^name is assigned to the blt_range within the given net_name. 
Bit.range can be either a single bit or a range. Subnet_name is a Tbl string. 

For example bit 3 of the MReqlnfo net may be assigned the name "cacheable" 
as follows: 

subnet MReqlnfo 3 cacheable 

Location Statement 

The location statement provides a way for the core to indicate where to place 
this interface when a schematic symbol for the core Is drawn. The location is 
specified as a compass direction of north(n), south(s), east(e), west(w) and a 
number. The number indicates a percentage from the top or left edge of the 
block. Syntax for the location statement is: 

location (n|e|w|s) <number> 

To place an interface on the bottom (south-side) in the middle (50% from the 
left edge) of the block, for example, use this definition: 

location s 50 
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Address Region Statement 

The address region statement specifies address regions within the complete 
address space of a core. It allows you to give a symbolic name to a region, and 
to specify Its base, size, and behavior. 

addrjregion <name> {<addr_region_body>*} 
where: 

<addr_region__body> : addr_base <integer> | addr_size <integer> 
| addr_space <integer> 

| proprietary <vendor_code> <organization_name> 
{<proprietary_statements>} 

• The addr_base statement specifies the base address of the region being 
defined and Is specified as an integer, 

• The addr_size statement similarly specifies the size of the region. 

• The addr_space statement specifies to which OCP address space the 
region belongs. If the addr_space statement is omitted, the region belongs 
to all address spaces. 

Proprietary Statement 

The proprietary statement enables proprietary extensions of the core RTL 
configuration file syntax. Standard parsers must be able to Ignore the exten- 
sions, while proprietary parsers can extract additional information about the 
core. Syntax for the proprietary statement is: 

proprietary <vendor_code> <organi2ation_name> 
{<proprietary_statements>} 

The vendor__code uniquely identifies the vendor associated with the propri- 
etary extensions and is described in more detail on page 66. 

The organization.name specifies the name of the organization that specified 
the extensions. Any number of proprietary statements can be included 
between the braces but must follow legal Tel syntax. 

The proprietary statement can be included at multiple levels of the syntax 
hierarchy, allowing it to use scoping to imply context. If multiple proprietary 
statements are included in a single scope, the parser must process these in 
an additive fashion. 
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Sample RTL Configuration File 

The format for a core RTL configuration file for a core Is shown In Example 1. 

Example 1 Sample flashctri^rtl.conf File 

# define the module 
version 2.5 

module flashctrl { 

core.id OxBBBB OxOOl 0x1 "Flash/Rom Controller* 

# Use the Vista icon 
icon "vista, pprn" 

addr_region "FLASHCTRLO* { 
addr_base 0x0 
addr_size 0x100000 
} 

# one of the interfaces is an OCP slave using the pre-defined OCP bundle 
interface tp bundle ocp { 

# version OCP 2.0 is used 
bundle_version 2.0 

# this is a slave type ocp interface 
inter face_type slave 

# this OCP is a basic interface with byteen support plus a named SFlag 

# and MReset_n 
param mreset 1 
param sreset 0 
param byteen 1 

param sflag 1 {width 1} 
param addr 1 {width 32} 
param mdata 1 {width 64} 
param sdata 1 {width 64} 

prefix tp 

# since the signal names do not exactly match the signal 

# names within the bundle, they must be explicitly linked 
port Reset_ni net MReset.n 

port Clk_i net Clk 

port TMCmd_i net MCmd 

port TMAddr_i net MAddr 

port TMByteEn_i net MByteEn 

port TMData_i net MData 

port TCCmdAccept_o net SCmdAccept 
port TCResp.o net SResp 
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port TCData_o net SData 

port TCError_o net SFlag 

# name SFlag [0] access_error 
subnet SFlag 0 access_error 

# stick this interface in the middle of the top of the module 
location n 50 

} # close interface tp defininition 



# The other interface is to the flash device defined in an interface file 

# Define the interface for the Flash control 
interface emem bundle flash { 

# the type indicates direction and drive of the control signals 
interface_type controller 

# since this module has direction indication on some of the signals 

# ('_o','_b') and is missing assertion level indicators '_n' on 

# some of the signals, the names must again be directly linked to 

# the signal names within the bundle 
port Addr_o net addr 

port Data_b net data 
port OE net oe_n 

port WE net we_n 

port RP net rp_n 

port WP net wp_n 

# all of the signals on this port have the prefix 'emem_' 
prefix "emejiL.' 1 

# stick this interface in the middle of the bottom of the module 
location s 50 



} # close interface emem defininition 



} # close module definition 



The flash bundle is defined in the following Interface configuration file. See 
•Interface Configuration File" on page 59 for the syntax definition of the inter- 
face configuration file. 

bundle flash { 

#types of flash interfaces 

tcontroller: flash controller; flash: flash device itself. 
interface_types controller flash 
net addr { 

#Address to the Flash device 
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direction output input 
width 19 

} 

net data { 

£Kead or Write Data 
direction inout inout 
width 16 

} 

net oe_n { 

# Output Enable, active low. 
direction output input 

} 

net we_n { 

# Write Enable, active low. 
direction output input 

} 

net rp_n { 

# Reset, active low. 
direction output input 

} 

net wp_n { 

# Write protect bit, Active low. 
direction output input 

} 

} 
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To connect two entitles together, allowing communication over an OCP Inter- 
face, the protocols, signals, and pin-level timing must be compatible. This 
chapter describes how to deflne Interface timing for a core. This process can 
be applied to OCP and non-OCP Interfaces. 

Use the core synthesis configuration file to set timing constraints for ports in 
the core. The file consists of any of the constraint sections: port, max delay, 
and false path. If the core has additional non-OCP clocks, the file should 
contain their definitions. 

When implementing IP cores in a technology independent manner it is diffi- 
cult to specify only one timing number for the interface signals, since timing 
is dependent on technology, libraiy and design tools. The methodology spec- 
ified in this chapter allows the timing of Interface signals to be specified in a 
technology Independent way. 

To make your core description technology independent use the technology 
variables defined in the Core Preparation Guide. The technology variables 
range from describing the default setup and clock-to-output times for a port 
to defining a high drive cell in the library. 
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Timing Parameters 

There Is a set of minimum timing parameters that must be specified for a core 
interface. Additional optional parameters supply more information to help the 
system designer integrate the core. Hold-time parameters allow hold time 
checking. Physical-design parameters provide details on the assumptions 
used for deriving pin-level timing. 



Minimum Parameters 

At a minimum, the timing of an OCP interface Is specified in terms of two 
parameters: 

• setuptime is the latest time an input signal is allowed to change before 
the rising edge of the clock. 

• c2qtine is the latest time an output signal is guaranteed to become stable 
after the rising edge of the clock. 

Figure 8 shows the definition of setuptime and c2qtime. See Tort 
Constraint Keywords" on page 85 for a description of these parameters. 



Figure 8 OCP Timing Parameters 
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Hold-time Parameters 

Hold- time parameters are needed to allow the system integrator to check hold 
time requirements. On the output side, c2qtimemin specifies the minimum 
time for a signal to propagate from a flip-flop to the given output pin. On the 
input side, holdtime specifies the minimum time for a signal to propagate 
from the input pin to a flip-flop. 
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Technology Variables 

To give meaning to the timing values, timing requirements on input and 
output pins must be accompanied by information on the assumed environ- 
ment for which these numbers are determined. This information also adds 
detail on the expected connection of the pin. 

For an input signal, the parameter drivingcellpin indicates the cell library 
name for a cell representative of the strength of the driver that needs to be 
used to drive the signal. This is shown in Figure 9. 

Figure 9 Driver Strength 
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For an output signal, the variable loadcellpin indicates the input load of the 
gate that the signal is expected to drive. The variable loads indicates how 
many loadcellpins the signal is expected to drive. Additionally, information on 
the capacitive load of the wire must be included. There are two options. Either 
the variable wireloaddelay can be specified, as shown in Figure 10. Or, the 
combination wireloadcapacitance/wireloadresistance must be speci- 
fied, as shown In Figure 11. 

Figure 10 Variable Loads - wireloaddelay 
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For instructions on calculating a delay, refer to the Synopsys Design Compiler 
Reference. 
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Figure 1 1 Variable Loads - wireloadresistance/wlretoadcapacltance 
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Connecting Two OCP Cores 

Figure 12 shows the timing model for interconnecting two OCP compliant 
cores. 

The sum of setuptime, c2qtime and wire delay must be less than the clock 
period or cycle time minus the clock-skew. Similarly, the minimum clock- 
cycle for two cores to Interoperate is determined by the maximum of the sum 
of c2qtime, setuptime. wire delay and clock-skew over all interface signals. 

The wireload delay Is defined by either the variable wireloaddelay or the set 
wirelcadcapacitance/wirelcadresistance. 

Figure 12 Connecting Two OCP Compliant Cores 
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Max Delay 

In addition to the setup and c2qtime paths for a core, there may also be 
combinational paths between Input and output ports. Use maxdelay to 
specify the timing for these paths. 

Figure 13 Max Delay Timing 



False Paths 

It Is possible to identify a path between two ports as being logically Impossible. 
Such paths can be specified using the f alsepath constraint syntax. 

For instructions on specifying the core's timing parameters, see "False Path 
Constraints* on page 90. 
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Core Synthesis Configuration File 

The core synthesis configuration file contains the following sections: 
Version 

Specifies the current version of the synthesis configuration file format 
The current version is 1.3. 

Clock 

Describes clocks brought into the core. 
Area 

Defines the area in gates of the core. 
Port 

Defines the timing of IP block ports. 
Max Delay 

Specifies the delay between two ports on a combinational path. 
False Path 

Specifies that a path between input and output ports 4s logically 
impossible. 

Syntax Conventions 

Observe the following syntax conventions: 

• Enclose all expr statements within braces { }. to differentiate between 
expressions that are to be evaluated while the file is being parsed (without 
braces) and those that are to be evaluated during synthesis constraint file 
generation (with braces), 

• Although not required by Tel. enclose strings within quotation marks 
to show that they are different than keywords. 

• Specify keywords using lower case. 

Parameter values are specified using Tel syntax. Expressions can use any of 
the technology or environment variables, and any of the following variables: 

clockperiod 

This variable should only be used In calculations of timing values for 
ports. When evaluating expressions that use $clockperiod, the program 
will determine which clock the port is relative to, determine its period {in 
nanoseconds), and apply that value to the equation. For example: 

port "in w ( 

setuptime {[expr $clockperiod * .5)} 

} 



OCP-IP Confidential 



Core Timing 83 



rootclockpeilod 

This variable is set to the period of the main system clock, usually referred 
to as the root clock. It is typically used when a value needs to be a multiple 
of the root clock, such as for non-OCP clocks. For example: 

clock "myClock" { 

period ([expr $rootclockperiod * 4]} 

} 

The design.syn.conf flle can also use conditional settings of the parameters 
in the design as outlined by the following arrays. These variables are only 
used at the time the file Is read into the tools. 

param 

This array is indexed by the configuration parameters that can be found 
on a particular instance. Only use param for core.syn.conf files since It is 
only applicable to the instance being processed. For example: 

if { $param( B dma_fd H ) == 1 } { 
port ,, Tl2_ipReset_no ,, { 

c2qtime {{expr $clockperiod * 0.7]} 

} 

} 

chipparam 

This array Is indexed by the configuration parameters that are defined at 
the chip or design level. These variables can be used In both the 
design_syn.conf and core__syn.conf flies as they are more global In nature 
than those specified by param. For example: 

if { $chipparam( B full fl ) == 1 } { 
instance "bigcore" { 
port "in" { 

setuptime {[expr $clockperiod * 0.7]} 

} 

} 

} 

Interfaceparam 

This anray is Indexed by the interface name and the configuration param- 
eters that are on an Interface. It should only be used for core_syn.conf flies 
since it is only applicable to the interfaces on the Instance being pro- 
cessed. In the following example the Interface name is ip. 

if { $interfaceparaIn( ,, ip_respaccept , ') == 1 } { 
port n ipMRespAccept_o° { 

c2qtime {(expr $clockperiod * 21/25]} 

} 
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Version Section 

The version of the core synthesis configuration file is required. Specify the 
version with the version command, for example: version 1 . 3 

Clock Section 

If you have non-OCP clocks for an IP block or want to specify the worst- 
casedelay of any clock (including OCP clocks) used in the core, specify the 
names of the clocks in the core synthesis configuration file. Use the following 
syntax to specify the name of the clock and its worstcasedelay: 

clock <clockName> { 

worstcasedelay <delay Value> 

} 

clockName refers to the name of the port that brings the clock Into the core 
for the core synthesis configuration file. For example: 

clock "myClock* 
worstcasedelay 

Hie worst case delay value is the longest path through the core or 
instance for a particular clock. The value is used to check that the core 
can meet the timing requirements of the current design. To help make this 
value more portable, you may want to use the technology variable 
gatedelay. For example: 

clock "myClock" { 

worstcasedelay {[10,5 * $gatedelay]} 

} 

clock "otherClock* { 
worstcasedelay 5 

} 

Constant values are specified in nanoseconds. For consistency, use 
expressions that can be interpreted in nanoseconds. 

Area Section 

The area is the size in gates of the core or instance. By specifying the size in 
gates the area can be calculated based on the size of a typical two input nand 
gate in a particular synthesis library. For example: 

area {[expr 20500 / $gatesize]} 
area 5000 

Constant values are specified in two input nand gate equivalents. For consis- 
tency, use expression that can be interpreted in gates. 
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Port Constraints Section 

Use the port constraints section to specify the timing parameters. Input port 
information that can be specified Includes the setup time, related clock (non- 
OCP ports), and driving cell. For output ports, the clock to output times, 
related clock (non-OCP ports), and the loading information must be supplied. 

Port Constraint Keywords 

The keywords that can be used to specify information about port constraints 
are: 

c2qtime 

The c2q (clock to q or clock to output) time Is the longest path using worst 
case timing from a starting point in the core (register or input port) to the 
output port This includes the c2qtime of the register. To maintain port- 
ability, most cores specify this as a percentage of the fastest clock period 
used while synthesizing the core. For example: 

c2qtime { [expr $timescale * 3500]} 
c2qtime {(expr $clockperiod * 0.25]) 

Constant values are specified in nanoseconds. For consistency, use ex- 
pressions that can be interpreted in nanoseconds. 

c2qtimemin 

The c2q (clock to q or clock to output) time min is the shortest path using 
best case timing from a starting point in the core {register or input port) 
to the output port This includes the c2qtime of the register. Most cores 
use the default from the technology section, def aultc2qtimenun. For ex- 
ample: 

c2qtimemin {[expr $timescale * 100]} 
c2qtimemin {$defaultc2qtimemin} 

Constant values are specified in nanoseconds. For consistency, use ex- 
pressions that can be interpreted in nanoseconds. 

clockname 

This is an optional field for all OCP ports and is a string specifying the 
associated clock portname. For input ports, input delays use this clock as 
the reference clock. For output ports, output delays use this clock as the 
reference clock. For example: 

clockname *myClock-* 
drivingcellpin 

This variable describes which cell in the synthesis library is expected to 
be driving the input To maintain portability set this variable to use one of 
the technology values of high/medium/lowdrivegatepin. 

Values are a string that specifies the logical name of the synthesis library, 
the cell from the library, and the pin that will be driving an input for the 
core. The pin is optional. For example: 
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drivingcellpin {$mediumdrivegatepin} 
drivingcellpin "pt25u/nan<12/0" 

holdtlme 

The hold time Is the shortest path using best case timing from an input 
port to any endpolnt in the core. Most cores use the default from the tech- 
nology section, def aultholdtime. For example: 

holdtime {[expr $timescale * 100]} 
holdtime {$def aultholdtime} 

Constant values are specified in nanoseconds. For consistency, use ex- 
pressions that can be interpreted in nanoseconds. 

loadcellpin 

The name of the load library/cell/pin that this output port is expected to 
drive. The value is specified to the synthesis tool as the gate to use (along 
with the number of loads) in its load calculations for output ports of a 
module. For portability use the default 

Values are a string that specifies the logical name of the synthesis library, 
the cell from the library, and the pin that the load calculation is derived 
from. The pin is optional. For example: 

loadcellpin M pt25u/nand2/Il B 
loadcellpin {$defaultloadcellpin} 

loads 

The number of loadcellpins that this output port is expected to drive. The 
value is communicated to the synthesis tool as the number of loads to use 
in load calculations for output ports of a module. The typical setting for 
this is the technology value of def aultlcads. Values are an expression 
that evaluates to an integer. For example: 

loads 5 

loads {$defaultloads} 
maxfanout 

This keyword limits the fanout of an input port to a specified number of 
fanouts. To maintain portability set this variable in terms of the 
technology variable def ault fanout load. Constant values are specified 
in library units. For example: 

maxfanout {{expr $default fanout load * 1]} 
setuptime 

The longest path using worst case timing from an Input port to any end- 
point in the core. To maintain portability, most cores specify this as a per- 
centage of the fastest clock period used during synthesis of the core. For 
example: 

setuptime {[expr $timescale * 25003} 
setuptime {[expr $clockperiod * 0.253} 
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Constant values are specified in nanoseconds. For consistency, use ex- 
pressions that can be interpreted in nanoseconds* 

wireloaddelay 

Replaces capacitance/resistance as a way to specify expected delays 
caused by the interconnect. To maintain portability set this variable to use 
a technology value of long/medium/ shortnetdelay. 

The resulting values get added to the worst case clock-to-output times of 
the ports to anticipate net delays of connections to these ports. To improve 
the accuracy of the delay calculation cores should use the resistance and 
capacitance settings. 

You cannot specify both wireloaddelay and wirelcadresistance/ca- 
pacitance for the same port. For example: 

wireloaddelay {{expr $clockperiod * .25]} 
wireloaddelay {$mediumnetdelay} 

Constant values are specified in nanoseconds. For consistency, use ex- 
pressions that can be Interpreted in nanoseconds. 

wireloadresistance 

wireloadcapacitance 

Specify expected loading and resistance caused by the interconnect If 
available, specify both resistance and capacitance. To maintain portability 
set this variable to use one of the technology values of long/medium/ 
shortnetrcresistance/capacitance. 

If these constraints are specified they show up as additional loads and re- 
sistances on output ports of a module. You cannot use both wireloaddelay 
and wireloadresistance/capacitance for the same port 

Specify constant values as expressions that result in kOhms for resis- 
tance and picofarads (pfl for capacitance. For example: 

wireloadresistance {[expr $resistancescale * .09]} 
wireloadcapacitance {[expr $capacitancescale * .12]} 
wireloadresistance {$mediumnetrcresi stance} 
wireloadcapacitance {$mediumnetrccapacitance} 



Input Port Syntax 

For Input and Inout ports [iriout ports have both an input and an output defi- 
nition) use the following syntax: 

port <portName> { 

clockname <clockName> 
drivingcellpin <drivingCellName> 
setup time <Value> 
holdtime <Value> 
maxfanout <Value> 

} 
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Examples 

In the following example, the clock Is not specified since this is an OCP port 
and is known to be controlled by the OCP clock. If a clock were specified as 
something other than the OCP clock, an error would result 

port *MCmd_i" { 

drivingcellpin { $mediumdrivegatepin} 
setuptime {[expr $clockperiod * 0.2]} 

} 

In the following example, the setup time is required to be 2ns. Time constants 
are assumed to be in nanoseconds. Use the timescale variable to convert 
library units to nanoseconds. 

port *MAddr_i* { 

drivingcellpin { $mediumdrivegatepin} 
setuptime 2 

} 

The following example shows how to associate a non OCP clock to a port The 
example uses maxf anout to limit the fanout of mylnPort to 1. If the logic for 
mylnPort required it to fanout to more than one connection, the synthesis tool 
would add a buffer to satisfy the maxf anout requirement 

port "mylnPort" { 

clockname "myClock* 

drivingcellpin {$mediumdrivegatepinj 

setuptime 2 

maxfanout {[expr $defaultfanoutload * 11} 

} 

Output Port Syntax 

For output and Inout ports (lnout ports have both an Input and an output 
definition) use the following syntax: 

port <portName> { 

clockname <clockName> 
lcadcellpin <loadCellPinName> 
loads <Value> 

wireloadresistance <Value> 
wireloadcapacitance <Value> 
wireloaddelay <Value> 
c2qtime <Value> 
c2qtimemin <Value> 



You cannot specify both wireloaddelay and wirelcadresistance/capac- 
itance for the same port. 
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Examples 

In the following example, the clock Is not specified since this is an OCP port 
and Is known to be controlled by the OCP clock. 

port *SC^ndaccept_o ,, 

loadcellpin {$defaultlcadcellpin) 
loads {$defaultloads} 

wireloadresistance {$mediumnetrcresi stance} 
wireloadcapacitance ( $mediumnetrccapaci tance} 
c2qtime {[expr $clockperiod * 0.2]} 

} 

In the following example, the clock to output time is required to be 2 ns. Time 
constants are assumed to be in nanoseconds. Use the timescale variable to 
convert library units to nanoseconds. 

port *SResp_o* 

loadcellpin {$defaultlcadcellpin} 
loads {$defaultloads} 

wireloadresistance {$mediuinnetrcresistance} 
wireloadcapacitance {$mediumnetrccapaci tance} 
c2qtime 2 

} 

The following example shows how to associate a clock to an output port 

port "myOutPort" 

clockname "nryClock" 

loadcellpin {$defaultloadcellpin} 

loads 10 

wireloaddelay {$longnetdelay} 
c2qtime {[expr $clockperiod * .2]} 

} 



InOut Port Example 

port "Signal_io* 

drivingcellpin {$mediumdrivegatepin} 
setuptime {[expr $clockperiod * 0.21} 

} 

port *Signal_io B 

loadcellpin { $def aul tloadcellpin} 
loads {$defaultloads} 

wireloadresistance {$mediumnetrcresis tance} 
wireloadresistance {$mediumnetrccapaci tance} 
c2qtime {[expr $clockperiod * 0,2]} 
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Max Delay Constraints 

Using the max delay constraints you can specify the delay between two ports 
on a combinational path. This Is useful when synthesizing two communi- 
cating OCP interfaces. The syntax for maxdelay is: 

maxdelay { 

delay <delayValue> fromport <portName> toport <portttame> 



} 

where: <delayValue> can be a constant or a Tel expression. 

In the following example, a maxdelay of 3 ns is specified for the combinational 
path between mylnPortl and myOutPortl. A maxdelay of 50% of the clockpe- 
riod is specified for the path between myInPort2 and myOutPort2. The braces 
around the expression delay evaluation until the expression is used by the 
mapping program. 

maxdelay { 

delay 3 fromport n myInPortl ff toport *myOut?ortl 

delay {[expr $clockperiod *.5]} fromport *ntyInPort2* toport •my0utPort2 ,r 

} 



False Path Constraints 

Using the false path constraints you can specify that a path between certain 
input and output ports Is logically impossible. 

The syntax for f alsepath is: 

falsepath{ 

fromport <portName> toport <portName> 



} 

In the following example, a f alsepath is set up between mylnPortl and 
myOutPortl as well as myInPort2 and myOutPort2. This tells the synthesis 
tool that the path is not logically possible and so it will not try to optimize this 
path to meet timing. 

falsepath { 

fromport n myInPortl* toport "myOutPortl * 

fromport "mylnPo^* toport *niy0utPort2* 

} 
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Sample Core Synthesis Configuration File 

The following example shows a complete core synthesis configuration flle. 

version 1.3 
port *Heset_ni ff { 

dr ivingcel Ipin { $mediumga tedrivepin} 

setuptime {[expr $clockperiod * .5]} 

} 

port *MCmd_i* { 

drivingcellpin {$mediumga tedrivepin} 
setuptirae {[expr $clockperiod * .9]} 

} 

port "MAddr_i" { 

drivingcellpin {$mediumga tedrivepin} 
setuptime {[expr Sclockperiod * .5]} 

J 

port "MWidth_i p { 

drivingcellpin {$mediumga tedrivepin} 
setuptime {{expr $clockperiod * .5]} 

} 

port "2«iData_i w { 

drivingcellpin {$mediumgatedrivepin} 
setuptime {[expr $clockperiod * .5]} 

} 

port "SCmdAccept.o* { 

loadcellpin { $def aul tloadcel Ipin} 
loads {$defaultloads} 
wireloaddelay { $mediumnetdelay} 
c2qtime {[expr $clockperiod * .9]} 

} 

port tt SResp_o" { 

loadcellpin {$defaultloadcellpin} 
loads {Sdefaultloads} 
wireloaddelay {$mediumnetdelay} 
c2qtime {[expr $clockperiod * .8]} 

} 

port n SData_o* { 

loadcellpin {$defaultloadcellpin} 
loads { $def aul tloads } 
wireloaddelay {$mediumnetdelay} 
c2gtime {[expr $clockperiod * .8]} 

} 

maxdelay { 

delay 2 fromport *MData_i" toport 
*SResp_o* 

} 

falsepath { 

fromport *MData_i" toport °SData_o* 
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8 Timing Diagrams 



The timing diagrams within this chapter look at signals at strategic points and 
are not intended to provide full explanations but rather, highlight specific 
areas of interest The diagrams are provided solely as examples. For related 
information about phases, see "Signal Timing and Protocol Phases* on 
page 33. 

Most fields are unspecified whenever their corresponding phase is not 
asserted. This is indicated by the striped pattern in the waveforms. For 
example, when MCmd is IDLE the request phase is not asserted, so the values 
of MAddr, MData, and SCmdAccept are unspecified. 

Subscripts on labels in the timing diagrams denote transfer numbers that can 
be helpful in tracking a transfer across protocol phases. 

For a description of timing diagram mnemonics, see Tables 2 and 3 on 
page 14. 
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Simple Write and Read Transfer 

Figure 14 illustrates a simple write and a read transfer on a basic OCP inter- 
face. This diagram shows a write with no response enabled on the write, 
which is typical behavior for a synchronous SRAM or a register bank. 

Figure 14 Simple Write and Read Transfer 
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Sequence 

A. The master starts a request phase on clock 1 by switching the MCmd field 
from IDLE to WR. At the same time, it presents a valid address (Al) on 
MAddr and valid data {Dl} on MData. The slave asserts SCmdAccept in 
the same cycle, making this a O-latency transfer. 

B. The slave captures the values from MAddr and MData and uses them 
internally to perform the write. Since SCmdAccept is asserted, the request 
phase ends. 

C. The master starts a read request by driving RD on MCmd. At the same 
time, it presents a valid address on MAddr. The slave asserts SCmdAccept 
in the same cycle for a request accept latency of 0. 

D. The slave captures the value from MAddr and uses it internally to 
determine what data to present. The slave starts the response phase by 
switching SResp from NULL to DVA. The slave also drives the selected 
data on SData. Since SCmdAccept is asserted, the request phase ends. 

E. The master recognizes that SResp indicates data valid and captures the 
read data from SData, completing the response phase. This transfer has 
a request-to- response latency of 1. 
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Request Handshake 

Figure 15 Illustrates the basic flow-control mechanism for the request phase 
using SCmdAccept There are three writes with no responses enabled, each 
with a different request accept latency. 

Figure 15 Request Handshake 
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Sequence 

A. The master starts a write request by driving WR on MCmd and valid 
address and data on MAddr and MData, respectively. The slave asserts 
SCmdAccept in the same cycle, for a request accept latency of 0. 

B. The master starts a new transfer in the next cycle. The slave captures the 
write address and data. It deasserts SCmdAccept, indicating that it is not 
yet ready for a new request 

C. Recognizing that SCmdAccept is not asserted, the master holds all 
request phase signals (MCmd, MAddr, and MData). The slave asserts 
SCmdAccept in the next cycle, for a request accept latency of 1. 

D. Hie slave captures the write address and data. 

E. After 1 idle cycle, the master starts a new write request The slave 
deasserts SCmdAccept 

F. Since SCmdAccept Is asserted, the request phase ends. SCmdAccept was 
low for 2 cycles, so the request accept latency for this transfer is 2. The 
slave captures the write address and data. 
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Request Handshake and Separate Response 

Figure 16 Illustrates a single read transfer in which a slave introduces delays 
in the request and response phases. The request accept latency 2, corre- 
sponds to the number of clock cycles that SCmdAccept was deasserted. The 
request to response latency 3, corresponds to the number of clock cycles from 
the end of the request phase (D) to the end of the response phase (F). 

Figure 16 Request Handshake and Separate Response 
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Sequence 

A. The master starts a request phase by Issuing the RD command on the 
MCmd field. At the same time, it presents a valid address on MAddr, The 
slave is not ready to accept the command yet, so it deasserts SCmdAccept 

B. The master sees that SCmdAccept is not asserted, so it keeps all request 
phase signals steady. The slave may be using this information for a long 
decode operation, and It expects the master to hold eveiything steady 
until it asserts SCmdAccept 

C. The slave asserts SCmdAccept The master continues to hold the request 
phase signals. 

D. Since SCmdAccept Is asserted, the request phase ends. The slave 
captures the address, and although the request phase is complete, it is 
not ready to provide the response, so it continues to drive NULL on the 
SResp field. For example, the slave may be waiting for data to come back 
from an off-chip memory device. 

E. The slave is ready to present the response, so It issues DVA on the SResp 
field, and drives the read data on SData. 

F. The master sees the DVA response, captures the read data, and the 
response phase ends. 
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Write with Response 



Figure 17 fs the same example as the waveform on page 97 but with response 
on write enabled. The response is typically provided to the master In the same 
cycle as SCmdAccept, but could be delayed (if required to perform an error 
check for instance). On the first write transaction, the slave uses a default 
accept scheme, resulting in a O-wait state write transaction. Using fully- 
synchronous handshake, this condition is only possible when the slave's 
ability to accept a command depends solely on its internal state: any 
command issued by the master can be accepted. Same-cycle SCmdAccept 
could also be achieved using combinational logic. 



Figure 17 Write with Response 
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Sequence 

A- The master starts a write request by driving WR on MCmd and valid 
address and data on MAddr and MData, respectively* The slave having 
already asserted SCmdAccept for a request accept latency of 0, drives DVA 
on SResp to indicate a successful transaction. 

B. The master starts a new transfer in the next cycle. The slave captures the 
write address and data and deasserts SCmdAccept, indicating that it is 
not ready for a new request 

C. With SCmdAccept not asserted, the master holds all request phase 
signals (MCmd, MAddr. and MData). The slave asserts SCmdAccept in the 
next cycle, for a request accept latency of 1 and drives DVA on SResp to 
indicate a successful transaction. 

D. The slave captures the write address and data. 
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E. After 1 Idle cycle, the master starts a new write request The slave 
deasserts SCmdAccept 

F. Since SCmdAccept Is asserted, the request phase ends, SCmdAccept was 
low for 2 cycles, so the request accept latency for this transfer Is 2, The 
slave captures the write address and data. The slave drives DVA on SResp 
to Indicate a successful transaction. 

G. The master samples the response. 
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Non-Posted Write 

Figure 18 repeats the previous example for a non-posted write transaction. In 
this case the response must be returned to the master once the write opera- 
tion occurs. There Is no difference in the command acceptance, but the 
response may be significantly delayed. If this scheme Is used for all posting- 
sensitive transactions, the result Is decreased data throughput but higher 
system reliability. 

Figure 18 Request Handshake 
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Sequence 

A. The master starts a non-posted write request by driving WRNP on MCmd 
and valid address and data on MAddr and MData, respectively. The slave 
asserts SCmdAccept combinatorially, for a request accept latency of 0. 

B. The slave drives DVA on SResp to Indicate a successful first transaction. 

C. The master starts a new transfer. The slave deasserts the SCmdAccept, 
indicating It is not yet ready to accept a new request The master samples 
DVA on SResp and the first response phase ends. 

D. The slave asserts SCmdAccept for a request accept latency of 1. 

E. The slave captures the write address and data. 

F. The slave drives DVA on SResp to indicate a successful second 
transaction. 

G. The master samples DVA on SResp and the second response phase ends. 
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Burst Write 



Figure 19 illustrates a burst of four 32-bit words, incrementing precise burst 
write, with optional burst framing information (MReqLast). As the burst Is 
precise [with no response on write), the MBurstLength signal fs constant 
during the whole burst MReqLast flags the last request of the burst and 
SRespLast flags the last response of the burst The slave may either count 
requests or monitor MReqLast for the end of burst. 



Figure 19 Burst V/rite 
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Sequence 

A. The master starts the burst write by driving WR on MCmd, the first 
address of the burst on MAddr, valid data on MData, a burst length of four 
on MBurstLength, the burst code 1NCR on MBurstSeq, and asserts 
MBurstPrecise. MReqLast must be deasserted until the last request In the 
burst. The burst signals Indicate that this Is an Incrementing burst of 
precisely four transfers. The slave Is not ready for anything, so It deasserts 
SCmdAccept. 

B. The slave asserts SCmdAccept for a request accept latency of 1. 

C. The master Issues the next write In the burst. MAddr Is set to the next 
word-aligned address. For 32-bit words, the address is Incremented by 4. 
The slave captures the data and address of the first request 
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D. The master Issues the next write In the burst Incrementing MAddr. The 
slave captures the data and address of the second request 

E. The master issues the final write in the burst, Incrementing MAddr, and 
asserting MBurstLast The slave captures the data and address of the 
third request 

F. The slave captures the data and address of the last request 



Non-Pipelined Read 

Figure 20 shows three read transfers to a slave that cannot pipeline responses 
after requests. This is the typical behavior of legacy computer bus protocols 
with a single WATT or ACK signal. In each transfer, SCmdAccept is asserted 
in the same cycle that SResp is DVA. Therefore, the request-to-response 
latency Is always 0, but the request accept latency varies from 0 to 2. 

Figure 20 Non-PlpelJned Read 
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Sequence 

A, The master starts the first read request, driving RD on MCmd and a valid 
address on MAddr. The slave asserts SCmdAccept for a request accept 
latency of 0, When the slave sees the read command, it responds with DVA 
on SResp and valid data on SData. (This requires a combinational path in 
the slave from MCmd, and possibly other request phase fields, to SResp, 
and possibly other response phase fields.) 
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B. The master launches another read request. It also sees that SResp Is DVA 
and captures the read data from SData. The slave is not ready to respond 
to the new request so It deasserts SCmdAccept 

C. The master sees that SCmdAccept is low and extends the request phase. 
The slave Is now ready to respond In the next cycle, so it simultaneously 
asserts SCmdAccept and drives DVA on SResp and the selected data on 
SData. The request accept latency is 1. 

D. Since SCmdAccept is asserted, the request phase ends. The master sees 
that SResp is now DVA and captures the data. 

E. The master launches a third read request The slave deasserts 
SCmdAccept. 

F. The slave asserts SCmdAccept after 2 cycles, so the request accept latency 
is 2. It also drives DVA on SResp and the read data on SData. 

G. The master sees that SCmdAccept is asserted, ending the request phase. 
It also sees that SResp Is now DVA and captures the data. 
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Pipelined Request and Response 

Figure 21 shows three read transfers using pipelined request and response 
semantics. In each case, the request Is accepted immediately, while the 
response Is returned in the same or a later cycle. 

Figure 2 1 Pipelined Request and Response 
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Sequence 

A* The master starts the first read request, driving RD on MCmd and a valid 
address on MAddr. The slave asserts SCmdAccept, for a request accept 
latency of 0. 

B. Since SCmdAccept is asserted, the request phase ends. The slave 
responds to the first request with DVA on SResp and valid data on SData. 

C. The master launches a read request and the slave asserts SCmdAccept 
The master sees that SResp is DVA and captures the read data from 
SData. The slave drives NULL on SResp, completing the first response 
phase. 

D. The master sees that SCmdAccept is asserted, so it can launch a third 
read even though the response to the previous read has not been received. 
The slave captures the address of the second read and begins driving DVA 
on SResp and the read data on SData. 

E. Since SCmdAccept is asserted, the third request ends. The master sees 
that the slave has produced a valid response to the second read and 
captures the data from SData. The request-to-response latency for this 
transfer is L 



OCP-IP Confidential 



106 Open Core Protocol Specification 



F. The slave has the data for the third read, so It drives DVA on SResp and 
the data on SData. 

G. The master captures the data for the third read from SData. The request- 
to-response latency for this transfer is 2. 



Response Accept 



Figure 22 shows examples of the response accept extension used with two 
read transfers. An additional field, MRespAccept, Is added to the response 
phase. This signal may be used by the master to flow-control the response 
phase. 



Figure 22 Response Accept 
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Sequence 

A. The master starts a read request by driving RD on MCmd and a valid 
address on MAddr. The slave asserts SCrndAccept immediately, and it 
drives DVA on SResp and the read data on SData as soon as it sees the 
read request. The master is not ready to receive the response for the 
request it just Issued, so it deasserts MRespAccept 

B. Since SCrndAccept Is asserted, the request phase ends. The master 
continues to deassert MRespAccept, however. The slave holds SResp and 
SData steady. 
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C. The master starts a second read request and is ready for the response 
from its first request, so it asserts MRespAccept. This corresponds to a 
response accept latency of 2. 

D. Since SCmdAccept is asserted, the request phase ends. The master 
captures the data for the first read from the slave. Since MRespAccept is 
asserted, the response phase ends. The slave is not ready to respond to 
the second read, so it drives NULL on SResp. 

E. The slave responds to the second read by driving DVA on SResp and the 
read data on SData. The master is not ready for the response, however, so 
it deasserts RespAccept 

F. The master asserts MRespAccept, for a response accept latency of 1. 

G. The master captures the data for the second read from the slave. Since 
MRespAccept is asserted, the response phase ends. 
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Incrementing Precise Burst Read 



Figure 23 Illustrates a burst of four 32-bJt words, Incrementing precise burst 
read, with burst framing Information (MReqLast/SRespLast). Since the burst 
is precise, the MBurstLength signal is constant during the whole burst 
MReqLast flags the last request of the burst, and SRespLast flags the last 
response of the burst 

Figure 23 Incrementing Precise Burst Read 
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Sequence 

A. The master starts a read request by driving RD on MCmd, a valid address 
on MAddr, four on MBurstLength, INCR on MBurstSeq, and asserts 
MBurstPrecise. MBurstLength, MBurstSeq and MBurstPrecise must be 
kept constant during the burst MReqLast must be deasserted until the 
last request in the burst. The slave Is ready to accept any request, so it 
asserts SCmdAccept 
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B. The master issues the next read in the burst. MAddr is set to the next 
word- aligned address (incremented by 4 In this case). The slave captures 
the address of the first request and keeps SCmdAccept asserted. 

C. The master issues the next read in the burst MAddr is set to the next 
word- aligned address (incremented by 4 in this case). The slave captures 
the address of the second request and keeps SCmdAccept asserted. The 
slave responds to the first read by driving DVA on SResp and the read data 
on SData. 

D. The master issues the last request of the burst, incrementing MAddr and 
asserting MReqLasL The master also captures the data for the first read 
from the slave. The slave responds to the second request, and captures 
the address of the third request 

E. The master captures the data for the second read from the slave. The slave 
responds to the third request and captures the address of the fourth. 

F. The master captures the data for the third read from the slave. The slave 
responds to the fourth request and asserts SRespLast to indicate the last 
response of the burst. 

G. The master captures the data for the last read from the slave, ending the 
last response phase. 
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Incrementing imprecise Burst Read 

Figure 24 Illustrates a burst of four 32-bit words, Incrementing imprecise 
burst read, with burst framing information (MReqLast/SRespLast). MReqLast 
flags the last request of the burst and SRespLast flags the last response of the 
burst The last burst request is signaled primarily by driving the value 1 on 
MBurstLength. 

The burst length sequence (3,3.2,1) is chosen arbitrarily for illustration 
purposes. The protocol requires that the burst length of the last transfer of 
the burst be equal to one. 

Figure 24 Incrementing Imprecise Burst Read 
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Sequence 

A. The master starts a read request by driving RD on MCmd, a valid address 
on MAddr, three on MBurstLength, INCR on MBurstSeq, and asserts 
MBurstPreclse, The burst length is the best guess of the master at this 
point. MBurstSeq and MBurstPreclse are kept constant during the burst. 
MReqLast must be deasserted until the last request in the burst The slave 
is ready to accept any request, so it asserts SCmdAccept 



OCP-IP Confidential 



Timing Dlograrns 111 



B. The master issues the next read In the burst MAddr is set to the next 
word-aligned address (incremented by 4 In this case). The MBurstLength 
is set to three, since the master knows the burst is longer than it originally 
thought. The slave captures the address of the first request and keeps 
SCmdAccept asserted* 

C. The master issues the next read in the burst MAddr is set to the next 
word- aligned address (incremented by 4 in this case). The MBurstLength 
is set to two. The slave captures the address of the second request, and 
keeps SCmdAccept asserted. The slave responds to the first read by 
driving DVA on SResp and the read data on SData. 

D. The master issues the last request of the burst, incrementing MAddr, 
setting MBurstLength to one, and asserting MReqLast The master also 
captures the data for the first read from the slave. The slave responds to 
the second request and captures the address of the last request 

E. The master captures the data for the second read from the slave. The slave 
responds to the third request 

F. The master captures the data for the third read from the slave. The slave 
responds to the fourth request and asserts SRespLast to indicate the last 
response of the burst 

G. The master captures the data for the last read from the slave, ending the 
last response phase. 
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Wrapping Burst Read 

Figure 25 illustrates a burst of four 32-bit words, wrapping burst read, with 
optional burst framing information (MReqLast/SRespLastJ. MReqLast flags 
the last request of the burst and SRespLast flags the last response of the 
burst. As a wrapping burst is precise, the MBurstLength signal is constant 
during the whole burst, and must be power of two. The wrapping burst 
address must be aligned to boundary MBurstLength times the OCP word size 
In bytes. 



Figure 25 V/rappIng Burst Read 
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Sequence 

A. The master starts a read request by driving RD on MCmd, a valid address 
on MAddr, four on MBurstLength, WRAP on MBurstSeq, and asserts 
MBurstPrecise, MBurstLength, MBurstSeq, and MBurstPrecise must be 
kept constant during the burst MReqLast must be deasserted until the 
last request in the burst The slave is ready to accept any request, so it 
asserts SCmdAccept 
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B. The master issues the next read in the burst MAddr is set to the next 
word-aligned address (Incremented by 4 in this case). The slave captures 
the address of the first request, and keeps SCmdAccept asserted, 

C. If incremented, the next address would be 0x10. Since the first transfer 
was from address 0x8 and the burst length is 4, the addresses must be 
between 0 and OxF. The master wraps the MAddr to 0, which is the closest 
alignment boundary. (If the first address were 0x14, the address would 
wrap to 0x10, rather than 0x20.) The slave captures the address of the 
second request, and keeps SCmdAccept asserted. The slave responds to 
the first read by driving DVA on SResp and valid data on SData* 

D. The master Issues the last request of the burst. Incrementing MAddr and 
asserting MReqLast The master also captures the data for the first read 
from the slave. The slave responds to the second request and captures the 
address of the third. 

E. The master captures the data for the second read from the slave. The slave 
responds to the third request and captures the address of the fourth. 

F. The master captures the data for the third read from the slave. The slave 
responds to the fourth request and asserts SRespLast to Indicate the last 
response of the burst 

G. The master captures the data for the last read from the slave, ending the 
last response phase. 
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Incrementing Burst Read with IDLE Request 
Cycle 

Figure 26 illustrates a burst of four 32-bit words. Incrementing precise burst 
read, with an IDLE cycle inserted in the middle. The master may insert IDLE 
requests in any burst type. 

Figure 26 Incrementing Precise Burst Read with IDLE Cycle 
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Sequence 

A. The master starts a read request by driving RD on MCmd, a valid address 
on MAddr, four on MBurstLength, INCR on MBurstSeq, and asserts 
MBurstPrecise. MBurstLength, MBurstSeq, and MBurstPrecise must be 
kept constant during the burst, MReqLast must be deasserted until the 
last request in the burst. The slave is ready to accept any request, so it 
asserts SCmdAccept. 
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B. The master issues the next read in the burst MAddr is set to the next 
word-aligned address (Incremented by 4 In this case). The slave captures 
the address of the first request and keeps SCmdAccept asserted, 

C. The master Inserts an IDLE request In the middle of the burst. The slave 
does not have to deassert SCmdAccept, anticipating more burst requests 
to come. The slave captures the address of the second request The slave 
responds to the flrst read by driving DVA on SResp and the read data on 
SData. The slave must keep SRespLast deasserted until the last response. 

D. The master issues the next read in the burst MAddr is set to the next 
word-aligned address (incremented by 4 in this case). The master also 
captures the data for the first read from the slave. The slave responds to 
the second read by driving DVA on SResp and the read data on SData, If 
it has the data available for response, the slave does not have to insert a 
NULL response cycle. 

E. The master issues the last request of the burst, incrementing MAddr, and 
asserting MReqLast The master also captures the data for the second 
read from the slave. The slave captures the address of the third request 
and responds to the third request 

F. The master captures the data for the third read from the slave. The slave 
captures the address of the fourth request The slave responds to the 
fourth request, and asserts SRespLast to Indicate the end of the slave 
burst 

G* The master captures the data for the last read from the slave, ending the 
last response phase. 
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Incrementing Burst Read with NULL Response 
Cycle 

Figure 27 illustrates a burst of four 32-bit words, Incrementing precise burst 
read, with a NULL response cycle (wait state) inserted by the slave. Null cycles 
can be inserted into any burst type by the slave. 

Figure 27 incrementing Burst Read with Null Cycle 
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Sequence 

A. The master starts a read request by driving RD on MCmd, a valid address 
on MAddr, four on MBurstLength, INCR on MBurstSeq, and asserts 
MBurstPrecise. MBurstLength, MBurstSeq and MBurstPrecise must be 
kept constant during the burst MReqLast must be deasserted until the 
last request in the burst. The slave is ready to accept any request, so it 
asserts SCmdAccept. 
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B. The master issues the next read In the burst MAddr is set to the next 
word-aligned address (Incremented by 4 In this case). The slave captures 
the address of the first request and keeps SCmdAccept asserted. The slave 
responds to the flrst request by driving DVA on SResp and the read data 
on SData. The slave must keep SRespLast deasserted until the last 
response. 

C. The master Issues the next read In the burst. MAddr is set to the next 
word-aligned address (Incremented by 4 In this case). The master also 
captures the data for the flrst read from the slave. The slave captures the 
address of the second request and keeps SCmdAccept asserted. The slave 
responds to the second request 

D. The master issues the last request of the burst. Incrementing MAddr and 
asserting MReqLast The master also captures the data for the second 
read from the slave. The slave captures the address of the third request 
and keeps SCmdAccept asserted* The slave responds to the third request 

E. The master captures the data for the third read from the slave. The slave 
captures the address of the fourth request and keeps SCmdAccept 
asserted. The slave cannot respond to the fourth request, so it inserts 
NULL to SResp, 

F. The slave responds to the fourth request and asserts SRespLast to 
Indicate the last response of the burst 

G. The master captures the data for the last read from the slave, ending the 
last response phase. 
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Single Request Burst Read 



Figure 28 illustrates a single request, multiple data burst read. The master 
provides the burst length, start address, and burst sequence, and Identifies 
the burst as a single request with the MBurstSingleReq signal. A single 
request burst Is always precise. 

Figure 28 Single Request Burst Read 
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Sequence 

A, The master starts a read request by driving RD on MCmd, a valid address 
on MAddr, four on MBurstLength, INCR on MBurstSeq, and asserts 
MBurstPrecIse, and MBurstSingleReq- The MBurstPrecIse and 
MBurstSingleReq signals would normally be tied off to logic 1, which !s not 
supplied by the master. The slave Is ready to accept any request, so It 
asserts SCmdAccept 
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B. The master completes the request cycles. The slave captures the address 
of the request. The slave responds to the request by driving DVA on SResp 
and the flrst response data on SData. The slave must keep SRespLast 
deasserted until the last response. 

C. The master captures the flrst response data. The slave issues the second 
response. 

D. The master captures the second response data. The slave issues the third 
response. 

E. TTie master captures the third response data. The slave Issues the fourth 
response, and asserts SRespLast to Indicate the last response of the 
burst 

F. The master captures the last response data. 



Datahandshake Extension 

ngure 29 shows three writes with no responses using the datahandshake 
extension. This extension adds the datahandshake phase, which is 
completely independent of the request and response phases. Two signals, 
MDataValld and SDataAccept, are added, and MData is moved from the 
request phase to the datahandshake phase. 



Figure 29 Datahondshoke Extension 
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Sequence 

A. The master starts a write request by driving WR on MCmd and a valid 
address on MAddr. It does not yet have the write data, however, so it 
deasserts MDataValid. The slave asserts SCmdAccept It does not need to 
assert or deassert SDataAccept yet, because MData Valid is still 
deasserted. 

B. The slave captures the write address from the master* The master Is now 
ready to transfer the write data, so It asserts MDataValid and drives the 
data on MData, starting the datahandshake phase. The slave is ready to 
accept the data Immediately, so It asserts SDataAccept This corresponds 
to a data accept latency of 0. 

C. The master deasserts MDataValid since it has no more data to transfer. 
[Like MCmd and SResp, MDataValid must always be in a valid, specified 
state.) The slave captures the write data from MData, completing the 
transfer. The master starts a second write request by driving WR on 
MCmd and a valid address on MAddr. 

D. Since SCmdAccept is asserted, the master Immediately starts a third write 
request It also asserts MDataValid and presents the write data of the 
second write on MData. The slave is not ready for the data yet, so it 
deasserts SDataAccept 

E. The master sees that SDataAccept is deasserted, so it holds the values of 
MDataValid and MData. The slave asserts SDataAccept, for a data accept 
latency of 1. 

F. Since SDataAccept is asserted, the datahandshake phase ends. The 
master is ready to deliver the write data for the third request, so it keeps 
MDataValid asserted and presents the data on MData- The slave captures 
the data for the second write from MData, and keeps SDataAccept 
asserted, for a data accept latency of 0 for the third write. 

G. Since SDataAccept is asserted, the datahandshake phase ends. The slave 
captures the data for the third write from MData. 
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Burst Write with Combined Request and Data 

Figure 30 illustrates a single request, multiple data burst write, with 
datahandshake signaling. Through the request handshake, the master 
provides the burst length, the start address, and burst sequence, and 
Identifies the burst as a single request with the MBurstSingleReq signal. 

The write data is transferred with a datahandshake extension {see Figure 29), 
The parameter reqdata_together forces the first data phase to start with the 
request, making the design of a slave state machine easier, since it only needs 
to track one request handshake during the burst. Without this parameter, the 
MDataValid signal could be asserted any time after the first request If 
datahandshake Is not used, a single- request write burst is not possible; 
instead a request Is required for each burst word. 

Figure 30 Burst Write with Combined Request and Data 
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Sequence 

A. The master starts a write request by driving WR on MCmd, a valid address 
on MAddr, INCR on MBurstSeq, five on MBurstLength, and asserts the 
MBurstPrecise and MBurstSingleReq signals* The master also asserts the 
MDataValid signal, drives valid data on MData, and deasserts MDataLast 
The MDataLast signal must remain deasserted until the last data cycle. 

B. Since it has not received SCmdAccept or SDataAccept, the master holds 
the request phase signals, keeps MDataValid asserted, and MData steady. 
The slave asserts SCmdAccept and SDataAccept to indicate it Is ready to 
accept the request and the first data phase. 

C. The master completes the request phase, asserts MDataValid and drives 
new data to MData. The slave captures the initial data and keeps 
SDataAccept asserted to indicate it is ready to accept more data. 

D. The master asserts MDataValid and drives new data to MData. The slave 
captures the second data phase and keeps SDataAccept asserted to 
indicate it is ready to accept more data. 

E. The master asserts MDataValid and drives new data to MData. The slave 
captures the third data phase and keeps SDataAccept asserted to indicate 
It is ready to accept more data. 

F. The master asserts MDataValid, drives new data to MData, and asserts 
MDataLast to Identify the last data in the burst The slave captures the 
fourth data phase and keeps SDataAccept asserted to indicate It is ready 
to accept more data. 

G. The slave captures the last data phase and address. 

This example also shows how the slave issues SResp at the end of a burst 
(when the optional write response Is configured in the interface). For single 
request / multiple data bursts there is only a single response, and it can be 
issued after the last data has been detected by the slave. The SResp is NULL 
until point G. in the diagram. The slave may use code DVA to indicate a 
successful burst, or ERR for an unsuccessful one. 
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Threaded Read 

Figure 31 illustrates out-of-order completion of read transfers using the OCP 
thread extension. This diagram is developed from Figure 21 on page 105. The 
thread IDs, MThreadlD and SThreadID, have been added, and the order of two 
of the responses has been changed. 

Figure 3 1 Threaded Read 
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Sequence 

A. The master starts the first read request, driving RD on MCmd and a valid 
address on MAddr. The master also drives a 0 on MThreadlD, indicating 
that this read request is for thread 0. The slave asserts SCmdAccept, for 
a request accept latency of 0. When the slave sees the read command, It 
responds with DVA on SResp and valid data on SData. The slave also 
drives a 0 on SThreadID, indicating that this response Is for thread 0. 

B. Since SCmdAccept Is asserted, the request phase ends. The master sees 
that SResp Is DVA and captures the read data from SData. Because the 
request was accepted and the response was presented in the same cycle, 
the request-to-response latency Is 0. 

C. The master launches a new read request, but this time it Is for thread 1 . 
The slave asserts SCmdAccept, however, it is not ready to respond. 
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D. Since SCmdAccept Is asserted, the master can launch another read 
request This request Is for thread 0, so MThreadID Is switched back to 0. 
The slave captures the address of the second read for thread 1, but It 
begins driving DVA on SResp, data on SData. and a 0 on SThreadlD. This 
means that It is responding to the third read, before the second read, 

E. Since SCmdAccept is asserted, the third request ends. The master sees 
that the slave has produced a valid response to the third read and 
captures the data from SData. The request-to-response latency for this 
transfer is 0, 

F. The slave has the data for the second read, so it drives DVA on SResp. 
data on SData, and a 1 on SThreadlD* 

G. The master captures the data for the second read from SData. The 
request-to-response latency for this transfer Is 3. 



OCP-IP Confidential 



Timing Dfogroms 125 



Threaded Read with Thread Busy 

Figure 32 illustrates the out-of-order completion of read transfers using the 
OCP thread extension. The change to Figure 31 is the addition of thread busy 
signals. In this example, the thread busy is only a hint, since the 
sthreadbusy_exact parameter is not set. In this case the master may ignore 
the SThreadBusy signals, and the slave does not have to accept requests even 
when it is not busy. 

When thread busy is treated as a hint and a request or thread is not accepted, 
the interface may block for all threads. Blocking of this type can be avoided 
by treating thread busy as an exact signal using the sthreadbusy__exact 
parameter. For an example, see Threaded Read with Thread Busy Exact". 

This example shows only the request part of the read transfers. The response 
part can use a similar mechanism for thread busy. 



Figure 32 Threaded Read with Thread Busy 
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Sequence 

A. The master starts the first read request, driving RD on MCmd and a valid 
address on MAddr. The master also drives a 0 on MThreadID, associating 
this read request with thread 0. The slave asserts SCmdAccept for a 
request accept latency of 0. 

B. Since SCmdAccept is asserted, the request phase ends. 
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C. The slave asserts SThreadBusy[l] since it is not ready to accept requests 
on thread 1. The master ignores the hint, and launches a new read 
request for thread 1 . The master can issue a request even though the slave 
asserts SThreadbusy (see transfer 2). All threads are now blocked. 

D. The slave deasserts SThreadBusy[ll and asserts SCmdAccept to complete 
the request for thread 1, 

E. Since SCmdAccept is asserted, the second request ends. The master 
issues a new request to thread 0, The slave is not ready to accept the 
request, and indicates this condition by keeping SCmdAccept deasserted. 
It chooses not to assert SThreadBusy[0]. The slave does not have to assert 
SCmdAccept for a request, even If it did not assert SThreadbusy (see 
transfer 3). 

F. The slave asserts the SCmdAccept to complete the request on thread 0. 

G. The master captures the SCmdAccept to complete the requests. 
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Threaded Read with Thread Busy Exact 

Figure 33 Illustrates the out-of-order completion of read transfers using the 
OCP thread extension. Because the sthreadbusy_exact parameter Is set, 
the master may not Ignore the SThreadBusy signals. The master Is using 
SThreadBusy to control thread arbitration, so it cannot present a command 
on Thread 1 as the slave asserts SThreadbusy{l]. 

This example shows only the request part of the read transfers. The response 
part can use a similar mechanism for thread busy. 

Figure 33 Threaded Read with Thread Busy Exact 
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Sequence 

A. The master starts the first read request, driving FID on MCmd and a valid 
address on MAddr. The master also drives a 0 on MThreadID, indicating 
that this read request is for thread 0. 

B. Since SThreadBusy[OJ is not asserted, the request phase ends. The slave 
samples the data and address and asserts SThreadBusyll! since it is not 
ready to accept requests on thread 1. The master is prevented from 
sending a request on thread 1, though it can send a request on another 
thread. 

C. The slave deasserts SThreadBusyll] and the master can send the request 
on thread 1 , 

D. Since SThreadBusyll] is not asserted, the request phase ends and the 
slave must sample the data and address. The master can send a request 
on thread 0 (or thread 1). 
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E. Since SThreadBusylO] is not asserted, the request phase ends and the 
slave must sample the data and address. 

Reset 

Figure 34 shows the timing of the reset sequence with MReset.n driven from 
the master to the slave. MReset_n must be asserted for at least 16 cycles of 
Clk to ensure that the master and slave reach a consistent Internal state. 

Figure 34 Reset Sequence 
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Sequence 

A. MReset_n Is sampled active on this clock edge. Master and slave now 
Ignore all other OCP signals. 

B. MReset_n Is asserted for at least 16 Clk cycles. 

C. A new transfer may begin on the same clock edge that MReseOi 19 
sampled deasserted. 
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This chapter collects examples and Implementation tips that can help you 
make effective use of the Open Core Protocol and does not provide any addi- 
tional specification material This chapter groups together a variety of topics 
including discussions of: 

!• The basic OCP with an emphasis on signal timing, state machines and 
OCP subsets, 

2, Simple extensions that cover byte enables, multiple address spaces and 
in-band Information 

3, An overview of the new 2.0 burst capabilities 

4, The concepts of threading and connections 

5. OCP features addressing the new write semantics, synchronization 
issues, and endianness 

6. Sideband signals with an emphasis on reset management 

7. A description of the debug and test interface 



Basic OCP 

This section considers the different OCP phases, their relationships, and 
identifies sensitive timing-related areas. The section includes descriptions of 
OCP compliant state machines, and also discusses the OCP parameters 
needed to define simple OCP Interfaces. 
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Signal Timing 

The Open Core Protocol data transfer model allows many different types of 
existing legacy IP cores to be bridged to the OCP without adding expensive 
glue logic structures that include address or data storage. As such, it is 
possible to draw many state machine diagrams that are compliant with the 
OCP protocol. This section describes some common state machine models 
that can be used with the OCP, together with guidance on the use of those 
models. 

Two-way handshaking is the general principle of the dataflow signals in the 
OCP interface. A group of signals is asserted and must be held steady until 
the corresponding accept signal is asserted, This allows the receiver of a 
signal to force the sender to hold the signals steady until it has completely 
processed them. This principle produces Implementations with fewer latches 
for temporary storage. 

OCP principles are built around three fundamental decoupled phases; the 
request phase, the response phase, and the datahandshake phase. 

Request Phase 

Request flow control relies on standard request/accept handshaking signals: 
MCmd and SCmdAccept. Note that in version 2.0 of this specification. 
SCmdAccept becomes an optional signal, enabled by the cmdaccept param- 
eter. When the signal is not physically present on the interface, it naturally 
defaults to 1, meaning that a request phase in that case lasts exactly one 
clock cycle. 

The request phase begins when the master drives MCmd to a value other than 
Idle. When MCmd != Idle, MCmd is referred to as asserted. All of the other 
request phase outputs of the master must become valid during the same clock 
cycle as MCmd asserted, and be held steady until the request phase ends. The 
request phase ends when SCmdAccept is sampled asserted (true) by the rising 
edge of Clk. The slave can assert SCmdAccept in the same cycle that MCmd 
is asserted, or stay negated for several Clk cycles. The latter choice allows the 
slave to force the master to hold its request phase outputs until the slave can 
accomplish its access without latching address or data signals. 

The slave designer chooses the delay between MCmd asserted and SCmdAc- 
cept asserted based on the desired area, timing, and throughput 
characteristics of the slave. 

As the request phase does not begin until MCmd is asserted, SCmdAccept is 
a "don't care" while MCmd is not asserted so SCmdAccept can be asserted 
before MCmd. This allows some area- sensitive, low frequency slaves to tie 
SCmdAccept asserted, as long as they can always complete their transfer 
responsibilities in the same cycle that MCmd is asserted. Since an MCmd 
value of Idle specifies the absence of a valid command, the master can assert 
MCmd Independently of the current setting of SCmdAccept. 

The highest throughput that can be achieved with the OCP is one data 
transfer per Clk cycle. High-throughput slaves can approach this rate by 
providing sufficient internal resources to end most request phases in the 
same Clk cycle that they start. This Implies a combinational path from the 
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master's MCmd output into slave logic, then back out the slaves SCmdAccept 
output and back Into a state machine In the master. If the master has addi- 
tional requests to present, it can start a new request phase on the next Clk 
cycle. Achieving such high throughput In high-frequency systems requires 
careful design Including cycle time budgeting as described in "Level2 Timing" 
on page 162. 

Response Phase 

The response phase begins when the slave drives SResp to a value other than 
NULL. When SResp 1= NULL, SResp is referred to as asserted. All of the other 
response phase outputs of the slave must become valid during the same Clk 
cycle as SResp asserted, and be held steady until the response phase ends. 
The response phase ends when MRespAccept is sampled asserted (true) by 
the rising edge of Clk; if MRespAccept is not configured into a particular OCP, 
MRespAccept is assumed to be always asserted (that is, the response phase 
always ends in the same cycle it begins). If present, the master can assert 
MRespAccept in the same cycle that MResp is asserted, or it may stay negated 
for several Clk cycles. The latter choice allows the master to force the slave to 
hold its response phase outputs so the master can finish the transfer without 
latching the data signals. 

Since the response phase does not begin until SResp Is asserted, MRespAc- 
cept Is a "don't care* while SResp Is not asserted so MRespAccept can be 
asserted before SResp. Since an SResp value of NULL specifies the absence of 
a valid response, the slave can assert SResp independently of the current 
setting of MRespAccept 

In high-throughput systems, careful use of MRespAccept can result In signif- 
icant area savings. To maintain high throughput, systems traditionally 
Introduce pipelining, where later requests begin before earlier requests have 
finished. Pipelining is particularly important to optimize Read accesses to 
main memory* 

The OCP supports pipelining with its basic request/response protocol, since 
a master is free to start the second request phase as soon as the first has 
finished (before the first response phase. In many cases). However, without 
MRespAccept, the master must have sufficient storage resources to receive all 
of the data it has requested. This is not an issue for some masters, but can 
be expensive when the master is part of a bridge between subsystems such 
as computer buses. While the original system initiator may have enough 
storage, the intermediate bridge may not. if the slave has storage resources 
{or the ability to flow control data that it is requesting), then allowing the 
master to de-assert MRespAccept enables the system to operate at high 
throughput without duplicating worst-case storage requirements across the 
die. 

If a target core natively includes buffering resources that can be used for 
response flow control at little cost, using MRespAccept can reduce the 
response buffering requirement in a complex SOC interconnect. 

Most simple or low-throughput slave IP cores need not implement MRespAc- 
cept Misuse of MRespAccept makes the slave's Job more difficult, because it 
adds extra conditions (and states) to the slave's logic. 
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Datahandshake Phase 

The datahandshake extension allows the de-coupling of a write address from 
write data. The extension is typically only useful for master and slave devices 
that require the throughput advantages available through transfer pipelining 
(particularly memory). When the datahandshake phase is not present in a 
configured OCP, MData becomes a request phase signal. 

The datahandshake phase begins when the master asserts MDataValid. The 
other datahandshake phase outputs of the master must become valid during 
the same Clk cycle while MDataValid is asserted, and be held steady until the 
datahandshake phase ends. The datahandshake phase ends when SDataAc- 
cept is sampled asserted (true) by the rising edge of Clk. The slave can assert 
SDataAccept in the same cycle that MDataValid is asserted, or it can stay 
negated for several Clk cycles. The latter choice allows the slave to force the 
master to hold its datahandshake phase outputs so the slave can accomplish 
its access without latching data signals. 

The datahandshake phase does not begin until MDataValid is asserted. While 
MDataValid is not asserted, SDataAccept is a "don't care". SDataAccept can 
be asserted before MDataValid. Since MDataValid not being asserted specifies 
the absence of valid data, the master can assert MDataValid independently of 
the current setting of SDataAccept. 

State Machine Examples 

The sample state machine implementations in this section use only the 
features of the basic OCP, request and response phases (the datahandshake 
phase is not discussed here but can be derived). The examples highlight the 
flexibility of the basic OCR 

Sequential Master 

The first example is a medium-throughput, high-frequency master design. To 
achieve high frequency, the implementation is a completely sequential (that 
is, Moore state machine) design. Figure 35 shows the state machine associ- 
ated with the master's OCP. 



OCP-IP Confidential 



Developers Guidelines 1 33 



Figure 35 Sequential Master 
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Not shown Is the Internal circuitiy of the master. It Is assumed that the 
master provides the state machine with two control wire inputs, WrReq and 
RdReq, which ask the state machine to initiate a write transfer and a read 
transfer, respectively. The state machine indicates back to the master the 
completion of a transfer as it transitions to its Idle state. 

Since this Is a Moore state machine, the outputs are only a function of the 
current state. The master cannot begin a request phase by asserting MCmd 
until it has entered a requesting state (either write or read), based upon the 
WrReq and RdReq inputs. In the requesting states, the master begins a 
request phase that continues until the slave asserts SCmdAccept At this 
point (this example assumes write posting with no response on writes), a 
Write command Is complete, so the master transitions back to the idle state. 

In case of a Read command, the next state is dependent upon whether the 
slave has begun the response phase or not. Since MRespAccept is not enabled 
in this example, the response phase always ends in the cycle it begins, so the 
master may transition back to the idle state if SResp is asserted. If the 
response phase has not begun, then the next state is wait resp, where the 
master waits until the response phase begins. 

The maximum throughput of this design Is one transfer eveiy other cycle, 
since each transfer ends with at least one cycle of idle. The designer could 
improve the throughput (given a cooperative slave) by adding the state tran- 
sitions marked with dashed lines. This would skip the idle state when there 
are more pending transfers by Initiating a new request phase on the cycle 
after the previous request or response phase. Also, the Moore state machine 
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adds up to a cycle of latency onto the idle to request transition, depending on 
the arrival time of WrReq and RdReq. This cost is addressed in "Combina- 
tional Master" bri page 135. 

The benefits of this design style include very simple timing, since the master 
request phase outputs deliver a full cycle of setup time, and minimal logic 
depth associated with SResp. 

Sequential SJave 

An analogous design point on the slave side is shown in Figure 36, This slave's 
OCP logic is a Moore state machine. The slave Is capable of servicing an OCP 
read with one Clk cycle latency. On an OCP write, the slave needs the master 
to hold MData and the associated control fields steady for a complete cycle so 
the slave's write pulse generator will store the desired data into the desired 
location. The state machine reacts only to the OCP (the Internal operation of 
the slave never prevents it from servicing a request), and the only non-OCP 
output of the state machine is the enable (WE) for the write pulse generator. 

Figure 36 Sequential OCP Slave 
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The state machine begins in an idle state, where it de-asserts SCmdAccept 
and SResp. When it detects the start of a request phase, it transitions to either 
a read or a write state, based upon MCmd. Since the slave will always 
complete Its task in one cycle, both active states end the request phase (by 
asserting SCmdAccept), and the read state also begins the response phase. 
Since MRespAccept is not enabled In this example, the response phase will 
end in the same cycle It begins. Writes without responses are assumed so 
SResp is NULL during the write state. Finally, the state machine triggers the 
write pulse generator in its write state, since the request phase outputs of the 
master will be held steady until the state machine transitions back to Idle. 
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As Is the case for the sequential master shown in Figure 35 on page 133, this 
state machine limits the maximum throughput of the OCP to one transfer 
eveiy other cycle. There is no simple way to modify this design to achieve one 
transfer per cycle, since the underlying slave is only capable of one write eveiy 
other cycle. With a Moore machine representation, the only way to achieve one 
transfer per cycle is to assert SCmdAccept unconditionally (since it cannot 
react to the current request phase signals until the next Clk cycle). Solving 
this performance issue requires a combinational state machine- 
Since the outputs depend upon the state machine, the sequential OCP slave 
has attractive timing properties. It will operate at very high frequencies 
(providing the Internal logic of the slave can run that quickly). 

This state machine can be extended to accommodate slaves with internal 
latency of more than one cycle by adding a counting state between Idle and 
one or both of the active states. 



Combinational Master 

"Sequential Master* on page 132 describes the transfer latency penalty asso- 
ciated with a Moore state machine implementation of an OCP master. An 
attractive approach to improving overall performance while reducing circuit 
area is to consider a combinational Mealy state machine representation. 
Assuming that the internal master logic is clocked from Clk, it Is acceptable 
for the master's outputs to be dependent on both the current state, the 
internal RdReq and WrReq signals, and the slave's outputs, since all of these 
are synchronous to Clk. Figure 37 shows a Mealy state machine for the OCP 
master. The assumptions about the internal master logic are the same as In 
"Sequential Master" on page 132, except that there is an additional acknowl- 
edge (Ack) signal output from the state machine to the internal master logic 
to Indicate the completion of a transfer* 

This state machine asserts MCmd in the same cycle that the request arrives 
from the internal master logic, so transfer latency Is Improved. In addition, the 
state machine Is simpler than the Moore machine, requiring only two states 
instead of four. The request state is responsible for beginning and waiting for 
the end of the request phase. The wait resp state is only used on Read 
commands where the slave does not assert SResp In the same cycle it asserts 
SCmdAccept The arcs described by dashed lines are optional features that 
allow a transition directly from the end of the response phase into the begin- 
ning of the request phase, which can reduce the turn- around delay on multi- 
cycle Read commands. 
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Figure 37 Combinational OCP Master 
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The cost of this approach is in timing. Since the master request phase outputs 
become valid a combinational logic delay after RdReq and WrReq, there is less 
setup time available to the slave. Furthermore, if the slave is capable of 
asserting SCmdAccept on the first cycle of the request phase, then the total 
path is: 

Clk -> (RdReq | WrReq) -> MCmd -> SCmdAccept -> Clk. 

To successfully implement this path at high frequency requires careful anal- 
ysis. The effort is appropriate for highly latency- sensitive masters such as 
CPU cores. At much lower frequencies, where area is often at a premium, the 
Mealy OCP master is attractive because it has fewer states and the timing 
constraints are much simpler to meet This style of master design is appro- 
priate for both the highest-performance and lowest-performance ends of the 
spectrum. A Moore state machine implementation may be more appropriate 
at medium performance. 

Combinational Slave 

Achieving peak OCP data throughput of one transfer per cycle is most 
commonly implemented using a combinational Mealy state machine Imple- 
mentation. If a slave can satisfy the request phase in the cycle it begins and 
deliver read data in the same cycle, the Mealy state machine representation 
is degenerate - there is only one state in the machine. The state machine 
always asserts SCmdAccept in the first request phase cycle, and asserts 
SResp In the same cycle for Read commands {assuming no response on writes 
as in the write posting model). 
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Figure 38 Combinational OCP Slave 
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The Implementation shown In Figure 38, offers the ideal throughput of one 
transfer per cycle. This approach typically works best for low-speed I/O 
devices with FIFOs, medium-frequency but low-latency asynchronous SRAM 
controllers, and fast register flies. This is because the timing path looks like: 

Clk -> (master logic) -> MCmd -> (access Internal slave resource] -> SResp -> 
Clk 

This path is simplest to make when: 

• Clk frequency is low 

• Internal slave access time Is small 

• SResp can be determined based only on MCmd assertion (and not other 
request phase fields nor internal slave conditions) 

To satisfy the access time and operating frequency constraints of higher- 
performance slaves such as main memory controllers, the OCP supports 
transfer pipelining. From the state machine perspective, pipelining splits the 
slave state machine Into two loosely-coupled machines: one that accepts 
requests, and one that produces responses. Such machines are particularly 
useful with the burst extensions to the OCP, 



OCP Subsets 

It is possible to define simple interfaces - OCP subsets that are frequently 
required in complex SOC designs. The subsets provide simple Interfaces for 
HW blocks, typically with one-directional, non-addressed, or odd data size 
capabilities. Since most of the OCP signals can be individually enabled or 
disabled, a variety of subsets can be defined. For the command set, any OCP 
command needs to be explicitly declared as supported by the core with at 
least one command enabled In a subset. 
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Some sample Interfaces are listed in Table 24. For each example the non- 
default parameter settings are provided. The list of the corresponding OCP 
signals Is provided for reference. Subset variants can further be derived from 
these examples by enabling various OCP extensions. 



Table 24 OCP Subsets 



Usage 



Purpose 



Non-default 
parameters 



Signals 



Handshake-only 
OCP 



Simple request/acknowledge 
handshake, that can be used to 
synchronize two processing modules. 
Using OCP handshake signals with well- 
defined timing and semantics allows 
routing this synchronization process 
through an interconnect. The OCP 
command WR Is used for requests, other 
commands are disabled. 



read_enoble=0. Clk, MCmd, 
addr-O, mdatc=Q SCmdAccept 
sdata=0, resp=0 



Write-only OCP Interface for cores that only need to read_enable=rQ, Clk, M Addr, 

support writes. sdata=0, resp=0 MCmd, MData, 
. SCmdAccept 



Read-only OCP 


Interface for cores that only need to 
support reads* 


write_enable=0, 
mdata=0 


CUc MAddf. 
MCmd, 
SCmdAccept, 
SData. SResp 


FIFO Write-only 
OCP 


Interface to FIFO Input, 


read_enab!e=0 
addM). sdata=0, 
re$p=0 


Clk. MCmd, 

MData 

SCmdAccept 


FIFO Read-only 
OCP 


Interface to FIFO output. 


wrlte_enable=0, Clk, MCmd, 
addr=0. mdatc=0 SCmdAccept, 
SData SResp 


FIFO OCP 


Read and write interface to FiFO. 


addr=0 


Cik. MCmd 



MData, 
SCmdAccept, 
SData SResp 



Simple OCP Extensions 

The simple extensions to the OCP signals add support for higher-performance 
master and slave devices. Extensions include byte enable capability, multiple 
address spaces, and the addition of In-band socket- specific information to 
any of the three OCP phases (request, response, and datahandshake). 



Byte Enables 

Byte enable signals can be driven during the request phase for read or write 
operations, providing byte addressing capability, or partial OCP word 
transfer. This capability Is enabled by setting the byteen parameter to 1. 
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Even for simpler OCP cores, it is good practice to implement the byte enable 
extension, making byte addressing available at the chip level with no restric- 
tions for the host processors. 

When a datahandshake phase is used (typically for a single request-multiple 
data burst), bursts must have the same byte enable pattern on all write data 
words. It is often necessary to send or receive write byte enables with the write 
data. To provide full byte addressing capability, the MDataByteEn field can be 
added to the datahandshake phase. This field Indicates which bytes within 
the OCP data write word are part of the current write transfer. 

For example, on its master OCP port, a 2D-graphics accelerator can use vari- 
able byte enable patterns to achieve good transparent block transfer 
performance. Any pixel during the memory copy operation that matches the 
color key value is discarded in the write by de-asserting the corresponding 
byte enable In the OCP word. Another example is a DRAM controller that, 
when connected to a x!6-DDR device, needs to use the memory data mask 
lines to perform byte or 16-blt writes. The data mask lines are directly derived 
from the byte enable pattern. 

Unpacking operations Inside an Interconnect can generate variable byte 
enable patterns across a burst on the narrower OCP side, even if the pattern 
is constant on the wider OCP side. Such unpacking operations may also 
result in a byte enable pattern of all zeros. Therefore, it is mandatory that 
slave cores fully support 0 as a legal pattern. 

An OCP interface can be configured to include partial word transfers by using 
either the MByteEn field, or the MDataByteEn field, or both. 

• If only MByteEn is present, the partial word Is specified by this field for 
both read and write type transfers as part of the request phase. This is the 
most common case. 

• If only MDataByteEn Is present, the partial word is specified by this field 
for write type transfers as part of the datahandshake phase, and partial 
word reads are not supported. 

• If both MByteEn and MDataByteEn are present, MByteEn specifies partial 
words for read transfers as part of the request phase, and is don't care for 
write type transfers. MDataByteEn specifies partial words for write 
transfers as part of the datahandshake phase, and is don't care for read 
type transfers. 

Multiple Address Spaces 

Logically separate memory regions with unique properties or behavior are 
often scattered in the system address map. The MAddrSpace signal permits 
explicit selection of these separate address spaces. 

Address spaces typically differentiate a memory space within a core from the 
configuration register space within that same core, or differentiate several 
cores Into an OCP subsystem including multiple OCP cores that can be 
mapped at non-contiguous addresses, from the top level system perspective. 
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Another example of the usage of the addrspace extension is the case of an 
OCP-to-PCl bridge, since PCI natively supports address spaces for configura- 
tion registers, memory spaces and i/o spaces. 

In-Band Information 

OCP can be extended to communicate information that is not assigned 
semantics by the OCP protocol. This is true for out-of-band information (flag, 
control/status signals) and also for in-band Information. The designer or the 
chip level architect can deilne in-band extensions for the OCP phases. 

The fields provided for that purpose are MReqlnfo for the request phase* 
SResplnfo for the response phase, MDatalnfo for the request phase or the 
datahandshake phase, and SDatalnfo for the response phase. The presence 
and width of these fields can be controlled Individually. 

MReqlnfo 

Uses for MReqlnfo can include user/supervisor storage attributes, cacheable 
storage attributes, data versus program access, emulation versus application 
access or any other access-related information, such as dynamic endianness 
qualification or access permission information. 

MReqlnfo bits have no assigned meanings but have behavior restrictions. 
MReqlnfo is part of the request phase, so when MCmd is Idle, MReqlnfo is a 
"don't care". When MCmd is asserted, MReqlnfo must be held steady for the 
entire request phase. MReqlnfo must be constant across an entire transac- 
tion, so the value may not change during a burst This facilitates simple 
packing and unpacking of data at mismatched master/slave data widths, 
eliminating the transformation of information. 

SResplnfo 

Uses for SResplnfo can include error or status Information, such as FIFO full 
or empty indications, or data response endianness information. 

SResplnfo bits have no assigned meaning, but have behavior restrictions. 
SResplnfo is part of the response phase, so when SResp is NULL, SResplnfo 
is a "don't care". When SResp is asserted, SResplnfo must be held steady for 
the entire response phase. SResplnfo must be constant across an entire 
transaction, so the value may not change during responses to a burst This 
facilitates simple packing and unpacking of data at mismatched master/slave 
data width, eliminating the transformation of information. 

MDatalnfo and SDatalnfo 

MDatalnfo and SDatalnfo have slightly dliferent semantics. While they have 
no OCP-defined meaning, they may have packing/unpacking Implications. 
MDatalnfo and SDatalnfo are only valid when their associated phase is 
asserted (request or datahandshake phase for MDatalnfo, response phase for 
SDatalnfo). 
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Uses for the MDatalnfo and SDatalnfo fields might Include byte data parity In 
the low-order bits and/or data ECC values in the high-order (non-packable) 
bits. 

The low-order mdatainfobyte_wdth bits of MDatalnfo are associated with 
MData[7:0], and so forth for each higher-numbered byte within MData, so 
-that the low-order mdatainfobyte_wdth*(datajwdth/8) bits of MDataJnfo are 
associated with individual data bytes. Any remaining (upper) bits of 
MDatalnfo cannot be packed or unpacked without further specification, 
although such bits may be used in cases with matched data width, where no 
transformation is required. 

The difference between MReqlnfo and the upper bits of MDatalnfo is that only 
MDatalnfo is allowed to change during a burst transfer. A similar relationship 
exists between SRespInfo and SDatalnfo. 

A slave should be operable when all bits of MReqlnfo and MDatalnfo are 
negated; in other words, any MReqlnfo or MDatalnfo signals defined by an 
OCP slave, but not present in the master will normally be negated (driven to 
logic 0) in the tie off rules. A master should be operable when all bits of 
SRespInfo and SDatalnfo are negated. 



Burst Extensions 

A burst is basically a set of related OCP words. Burst framing signals provide 
a method for linking together otherwise-independent OCP transfers. This 
mechanism allows various parts of a system to optimize transfer performance 
using such techniques as SDRAM page-mode operation, burst transfers, and 
pre-fetching. 

Burst support is a key enabler of SOC performance. The burst extension is 
frequently used in conjunction with pipelined master and slave devices. For a 
pipelined OCP device, the request phase is de-coupled from the response 
phase - that is, the request phase may begin and end several cycles before the 
associated response phase begins and ends. As such, it is useful to think of 
separate, loosely-coupled state machines to support either the master or the 
slave. Decoupling for pipeline efficiency remains true even if the OCP includes 
a separate datahandshake phase. 

OCP-IP 2.0 Burst Capabilities 

The OCP burst model Includes a variety of options permitting close matching 
of core design requirements. 

Exact Burst Lengths and Imprecise Burst Lengths 

A burst can be either precise, of known length when issued by the initiator, 
or imprecise, the burst length is not specified at the start of the burst. 
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For precise bursts. MBurstLength Is driven to the same value throughout the 
burst, but is really meaningful only during the first request phase. Precise 
bursts with a length that Is a power-of-two can make use of the WRAP and 
XOR address sequence types. 

For imprecise bursts, MBurstLength can assume different values for words in 
the burst, reflecting a best guess of the burst length. MBurstLength is a hint 
Imprecise bursts are completed by a request with an MBurstLength=l, and 
cannot make use of the WRAP and XOR address sequence types. 

Use the precise burst model whenever possible: 

• It is compatible with the single request- multiple data model that provides 
advantages to the SOC in terms of performance and power. 

• Since it is deterministic, it simplifies burst conversion. Restricting burst 
lengths to power-of-two values and using aligned Incrementing bursts (by 
employing the burst_aligned parameter) also reduces the interconnect 
complexity needed to maintain interoperability between cores* 

Address Sequences 

Using the MBurstSeq field, the OCP burst model supports commonly-used 
address sequences. Benefits include: 

• A simple Incrementing scheme for regular memory type accesses 

• A constant addressing mode for FIFO oriented targets (typically 
peripherals) 

• Wrapping on power-of-two boundaries 

• XOR for processor cache line fill 

User-defined sequences can also be defined. They must be carefully docu- 
mented in the core specification, particularly the rules to be applied when 
packing or unpacking. The address behavior for the different sequence types 
is: 

INCR 

Each address is incremented by the OCP word size. Used for regular 
memory type accesses, SDRAM, SRAM, and burst Flash. 

STRM 

The address Is constant during the burst Used for streaming data to or 
from a target, typically a peripheral device including a FIFO interface that 
is mapped at a constant address within the system. 

DFLT1 

User-specified address sequence. Maximum packing Is required. 
DFLT2 

User-specified address sequence. Packing Is not allowed. 
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WRAP 

Similar to INCR, except that the address wraps at aligned MBurstLength 
* OCP word size. This address sequence is typically used for processor 
cache line fill. Burst length Is necessarily a power-of-two ( and the burst is 
aligned on its size. 

XOR 

Addr = BurstBaseAddress +(index of first request in burst) A {current word 
number). XOR Js used by some processors for critical-word first cache line 
fill from wide and slow memory systems, 

UNKN 

Indicates that there Is no specified relationship between the addresses of 
different words in the burst Used to group requests within a burst 
container, when the address sequence does not match the pre-defined 
sequences. For example, an initiator can group requests to non- 
consecutive addresses on the same SDRAM page, so that the target 
memory bandwidth can be increased. 

For targets that have support for some burst sequence, adding support for 
the UNKN burst sequence can improve the chances of interoperability 
with other cores and can ease verification since it removes all 
requirements from the address sequence within a burst 

For single requests. MBurstSeq Is allowed to be any value that is legal for that 
particular OCP interface configuration. 

The INCR, DFLT1, WRAP, and XOR burst sequences are always considered 
packing, whereas STRM and DFLT2 sequences are non-packing. Transfers in 
a packing burst sequence are aggregated / split when translating between 
OCP interfaces of different widths while transfers in a non-packing sequence 
are filled / truncated. 

The packing behavior of a bridge or interconnect for an UNKN burst sequence 
is system-dependent A common policy Is to treat an UNKN sequence as 
packing In a wide-to-narrow OCP request width converter, and as non- 
packing In a narrow- to-wide OCP request width converter. 

Single Request Multiple Data Bursts for Reads and Writes 

A burst model of this type can reduce power consumption, bandwidth conges- 
tion on the request path, and buffering requirement at various locations in the 
system. This model is only applicable for precise bursts, and assumes that the 
target core can reconstruct the full address sequence using the code provided 
in the MBurstSeq field. 

While the model assumes that the datahandshake extension is on, for those 
cores that do not accept the first-data word with the corresponding request, 
datahandshake can increase design and verification complexity. 

For such cores, use the OCP parameter reqdata_together to specify the fixed 
timing relationship between the request and datahandshake phases. When 
reqdata_together is set, the request and datahandshake phases of the first 
transfer in the single request / multiple data write-type burst begin and end 
together. 
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Unit of Atomicity 

Use this option when there is a requirement to limit burst Interleaving 
between several threads. Specifying the atomicity allows the master to deilne 
a transfer unit that is guaranteed to be handled as an atomic group of 
requests within the burst, regardless of the total burst length. The master 
indicates the size of the atomic unit using the MAtomicLength field. 

Burst Framing with all Transfer Phases 

Without burst framing information, cores and interconnects Incorporate 
counters in their control logic: To limit this extra gate count and complexity, 
enable end-of-burst Information for each phase. Use MReqLast to specify the 
last request within a burst, SRespLast to specify the last response within a 
burst, and MDataLast to specify the last write data during the datahandshake 
phase. 



Compatibility with the OCP 1.0 Burst Model 

The OCP-IP 2.0 burst model replaces the OCP-IP LO model, providing a 
superset in terms of available functionality. To maintain interoperability 
between cores using the OCP-IP 1.0 burst and cores using the OCP-IP 2.0 
bursts requires a thin adaptation layer. Guidelines for the wrapping logic are 
described In this section. 

1 .0 Master to 2.0 Slave 

For converting an OCP 1.0 burst into an OCP 2.0 burst the suggested 
mapping is: 

• MBurstPrecise is available only when the OCP 1.0 burst_aligned 
parameter is set. When set all incrementing bursts once converted to OCP 
2.0 stay precise. Any other OCP 1 .0 burst type is mapped to an Imprecise 
burst When burst.aligned is not set MBurstPrecise is tied off to 0, so all 
burst are imprecise. 

• MBurstSeq is derived from MBurst as follows: 

MBurstSeq = INCR for MBurst {CONT, TWO, FOUR, EIGHT} 
STRM for MBurst {STRM} 
DFLT1 for MBurst (DFLT1) 
DFLT2 for MBurst {DFLT2J 

The logic must guarantee that MBurstSeq Is constant during the whole 
burst and must continue driving that MBurstSeq when MBurst=LAST is 
detected. 

• The value of MBurstLength is derived as follows: 

MBurstLength = 8 for MBurst {EIGHT} 
4 for MBurst {FOUR} 

2 for MBurst {TWO, CONT, DFLT1, DFLT2, STRM) 
1 for MBurst {LASH 
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For precise bursts, MBurstLength is held constant for the entire burst 
For Imprecise bursts, a new MBurstLength can be derived for each 
transfer. 

• MReqLast Js derived from MBurst - it Is set when MBurst is LAST. 

• SRespLast has no equivalent in OCP1 .0, and is discarded by the wrapping 
logic. 

• If required, MDataLast must be generated from a counter or from a queue 
updated during the request phase. 

2.0 Master to 1 .0 Slave 

For converting an OCP 2.0 burst Into an OCP 1.0 burst the suggested 
mapping is: 

• MBurst is derived from MBurstPrecise, MBurstSeq and MBurstLength, as 
follows; 

MBurst = 

If MBurstPrecise 

if MBurstSeq {INCRJ 

EIGHT if MBurstLength >= 8 at start of burst 
FOUR if MBurstLength >= 4 at start of burst 
TWO if MBurstLength >= 2 at start of burst 
load counter with MBurstLength at start of burst, 
decrement counter after eveiy transfer 
subsequent MBurst are generated from counter logic 
LAST when counter==l 

else if MBurstSeq {DFLT1, DFLT2. STRM} 

same as MBurstSeq, except when counter==l, must be LAST 

else if MBurstSeq (WRAP, XOR, UNKN) 

LAST always: map to consecutive non-burst single transactions 

Else if not MBurstPrecise 
if MBurstSeq {INCR} 

EIGHT if MBurstLength >= 8 

FOUR if MBurstLength >= 4 

TWO if MBurstLength >= 2 

LAST if MBurstLength == 1 
else if MBurstSeq {DFLT1, DFLT2. STRM} 

LAST If MBurstLength == 1 

same as MBurstSeq if MBurstLength 1= 1 
else if MBurstSeq {WRAP, XOR, UNKN} 

LAST always (map to non-burst) 

• MAtomicLength, MReqLast, and MDataLast have no equivalents in OCP 
1.0, and are discarded by the wrapping logic. 

• SRespLast must be generated from counter logic. 

The logic described above is not suitable if the OCP 2.0 master generates 
single request / multiple data bursts. In that case, more complex conversion 
logic is required. 
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Threads and Connections 

Thread extensions add support for concurrency. Without these extensions, 
the OCP protocol enforces strict ordering constraints; each transfer request 
must be completed by the slave in the same order presented by the master. 
This restriction ensures proper system functionality (that is, an OCP read that 
occurs after a write to the same address will return the new data) and simpli- 
fies the transfer tracking requirements of implementing pipelining. Threading 
extensions enhance the basic transfer capability by introducing the concept 
of threads. 



Threads 

The thread capability relies on a thread ID to identify and separate indepen- 
dent transfer streams (threads). The master labels each request with the 
thread ID that It has assigned to the thread. The thread ID Is passed to the 
slave on MTTireadID together with the request (MCmd). When the slave 
returns a response, it also provides the thread ID (on SThreadID) so the 
master knows which request is now complete. 

The transfers in each thread must remain in-order with respect to each other 
(as in the basic OCP), but the order between threads can change between 
request and response. 

The thread capability allows a slave device to optimize its operations. For 
Instance, a multi-bank SDRAM controller could respond to a second read 
request referencing an open page before opening a new page In a different 
bank to service a first read on a different thread. 

As routing congestion and physical effects become Increasingly difficult at the 
back-end stage of the ASIC process, multithreading offers a powerful method 
of reducing wires. Many functional connections between initiator and target 
pairs do not require the full bandwidth of an OCP link, so sharing the same 
wires between several connections, based on functional requirements and 
floor planning data, is an attractive mechanism to perform gate count versus 
performance versus wire density trade-offs. 

Multi-threaded behavior is most frequently implemented using one state 
machine per thread. The only added complexity is the arbitration scheme 
between threads. This is unavoidable, since the entire purpose for building a 
multi-threaded OCP is to support concurrency, which directly implies conten- 
tion for any shared resources. 

The MDataThreadID signal simplifies the implementation of the datahand- 
shake extension along with threading, by providing the thread ID associated 
with the current write data transfer. When datahandshake is enabled, but 
sdatathreadbusy Is disabled, the ordering of the datahandshake phases must 
exactly match the ordering of the request phases. 

The thread busy signals provide status information that allows the master to 
determine which threads will not accept requests. That information also 
allows the slave to determine which threads will not accept responses. These 
signals provide for cooperation between the master and the slave to ensure 
that requests are not presented on busy threads. 
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While multithreading support has a cost in terms of gate count (buffers are 
required on a thread-per-thread basis Tor maximum efficiency), the protocol 
can ensure that the multi-threaded interface is non-blocking. 

Blocked OCP interfaces introduce a thread dependency. If thread X cannot 
proceed because the OCP interface is blocked by another thread, Y that is 
dependent on something downstream that cannot make progress until thread 
X makes progress, there is a classic circular wait condition that can lead to 
deadlock. 

In the OCP-IP1.0 specification, the semantics of SThreadBusy and MThread- 
Busy allow these signals to be treated as hints. To guarantee that a multi- 
threaded interface does not block, both master and slave need to be held to 
tighter semantics. 

OCP-1P 2.0 allows cores to specify that they are obeying exact thread busy 
semantics. This process enables tighter protocol checking at the interface and 
guarantees that a multi-threaded OCP interface Is non-blocking. Parameters 
to enable these extensions are sthreadbusy_exact. sdatathreadbusy_exact, 
and mthreadbusy_exact. There is one parameter for each of the OCP phases, 
request, datahandshake (assuming separate datahandshake) and response 
(assuming response flow control). The following conditions are true: 

• On an OCP interface that satisfies sthreadbusy_exact semantics, the 
master Is not allowed to Issue a command to a busy thread, 

• On an OCP interface that complies with sdatathreadbusy^exact 
semantics, the master Is not allowed to issue write data to a busy thread. 

• On an OCP interface that complies with mthreadbusy_exact semantics, the 
slave is not allowed to issue a response to a busy thread. 

These rules allow the phase accept signals (SCmdAccept, SDataAccept or 
MRespAccept) to be tied off to 1 on multi-threaded interfaces for which the 
corresponding phase handshake satisfies exact thread busy semantics. By 
eliminating an additional combinational dependency between master and 
slave, an exact thread busy based handshake can be considered as a substi- 
tute for the standard request/accept protocol handshake. For more 
information, see "Multi-Threaded OCP Implementation- on page 149. 

Intra-Phase Signal Relationships on a Multithreaded OCP 

This section extends the timing discussion of the "Basic OCP" section, to a 
multithreaded interface. The ordering and timing relationships between the 
signals within an OCP phase are designed to be flexible. As described in 
"Request Phase", it is legal for SCmdAccept to be driven either combination- 
ally, dependent upon the current cycle's MCmd or independently from MCmd, 
based on the characteristics of the OCP slave. Some restrictions are required 
to ensure that independently-created OCP masters and slaves will work 
together. For instance, the MCmd cannot respond to the current state of 
SCmdAccept; otherwise, a combinational cycle could occur. 
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Request Phase 

If enabled, a slave's SThreadBusy request phase output should not depend 
upon the current state of any other OCP signal. SThreadBusy should be 
stable early enough in the cycle so that the master can factor the current 
SThreadBusy Into the decision of which thread to present a request; that is, 
all of the master's request phase outputs may depend upon the current 
SThreadBusy. SThreadBusy Is a hint so the master Is not required to include 
a combinational path from SThreadBusy into MCmd, but such paths become 
unavoidable if the exact semantics apply [sthreadbusy_exact = 1). In that 
case the slave must guarantee that SThreadBusy becomes stable early in the 
OCP cycle to achieve good frequency performance. A common goal Is that 
SThreadBusy be driven directly from a flip-flop in the slave. 

A master's request phase outputs should not depend upon any current slave 
output other then SThreadBusy. This ensures that there is no combinational 
loop in the case where the slave's SCmdAccept depends upon the current 
MCmd. 

If a slave's SCmdAccept request phase output is based upon the master's 
request phase outputs from the current cycle, there Is a combinational path 
from MCmd to SCmdAccept. Otherwise. SCmdAccept may be driven directly 
from a flip-flop, or based upon some other OCP signals. It is legal for 
SCmdAccept to be derived from MRespAccept This case arises when the slave 
delays SCmdAccept to force the master to hold the request fields for a multi- 
cycle access. Once read data Is available, the slave attempts to return it by 
asserting SResp. If the OCP has MRespAccept enabled, the slave then must 
wait for MRespAccept before negating SResp, so it may need to continue to 
hold oil SCmdAccept until it sees MRespAccept asserted. 

While the phase relationships of the OCP specification do not allow the 
response phase to end before the request phase, it is legal for both phases to 
complete in the same OCP cycle. 

The worst-case combinational path for the request phase could be: 

Clk -> SThreadBusy -> MCmd -> SResp -> MRespAccept -> SCmdAccept -> Clk 

The preceding path has too much latency at typical clock frequencies, so must 
be avoided. Fortunately, a multi-threaded slave (with SThreadBusy enabled) 
is not likely to exhibit non-pipelined read behavior, so this path is unlikely to 
prove useful. Slave designers need to limit the combinational paths visible at 
the OCP. By pipelining the read request, the previous path could be: 

Clk -> SThreadBusy -> MCmd -> Clk 

Clk -> SCmdAccept -> Clk # Slave accepts if pipeline reg empty 
Clk -> SResp -> Clk 

Clk -> MRespAccept -> Clk # Master accepts independent of SResp 

Response Phase 

If enabled, a master's MThreadBusy response phase output should not be 
dependent upon the current state of any other OCP signal. From the perspec- 
tive of the OCP, MThreadBusy should become stable early enough in the cycle 
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that the slave can factor the current MThreadBusy into the decision on which 
thread to present a response; that is, all of the slave's response phase outputs 
may depend upon the current MThreadBusy. If MThreadBusy is simply a hint 
(in other words mthreadbusy_exact = 0) the slave is not required to include a 
combinational path from MThreadBusy Into SResp, but such paths become 
unavoidable if the exact semantics apply (mthreadbusy_exact = 1). In that case 
the master must guarantee that MThreadBusy becomes stable early in the 
OCP cycle to achieve good frequency performance. A common goal is that 
MThreadBusy be driven directly from a flip-flop In the master. 

The slave's response phase outputs should not depend upon any current 
master output other than MThreadBusy, This ensures that there is no combi- 
national loop in the case where the master's MRespAccept depends upon the 
current SResp. 

The master's MRespAccept response phase output may be based upon the 
slave's response phase outputs from the current cycle or not If this is true* 
there Is a combinational path from SResp to MRespAccept. Otherwise, 
MRespAccept can be driven directly from a flip-flop; MRespAccept should not 
be dependent upon other master outputs. 

Datahanclshake Phase 

If enabled, a slave's SDataThreadBusy datahandshake phase output should 
not depend upon the current state of any other OCP signal. SDataThreadBusy 
should be stable early enough in the cycle so that the master can factor the 
current SDataThreadBusy into the decision of which thread to present a data; 
that is, all of the master's data phase outputs may depend upon the current 
SDataThreadBusy. If SDataThreadBusy Is simply a hint (in other words 
sdatathreadbusy_exact = 0) the master Is not required to include a combina- 
tional path from SDataThreadBusy Into MDataValid, but such path becomes 
unavoidable if the exact semantics apply (sdatathreadbusy.exact = 1). In that 
case, the slave must guarantee that SDataThreadBusy becomes stable early 
In the OCP cycle to achieve good frequency performance. A common goal is 
that SDataThreadBusy be driven directly from a flip-flop In the slave. 

The master's datahandshake phase outputs should not depend upon any 
current slave output other than SThreadBusy. This ensures that there is no 
combinational loop in the case where the slave's SDataAccept depends upon 
the current MDataValid. The slave's SDataAccept output may or may not be 
based upon the master's datahandshake phase outputs from the current 
cycle. In the former case, there Is a combinational path from MDataValid to 
SDataAccept. In the latter case, SDataAccept should be driven directly from 
a flip-flop; SDataAccept should not be dependent upon other master outputs. 

Multi-Threaded OCP Implementation 

Figure 39 on page 150 shows the typical implementation of the combinational 
paths required to make a multi-threaded OCP work within the framework set 
by Level-2 timing. While the figure shows a request phase, similar logic can 
be used for the response and datahandshake phases. The top half of the 
figure shows logic In the master; the bottom half shows logic in the slave. The 
width of the figure represents a single OCP cycle. 
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Figure 39 Multithreaded OCP Interface Implementation 




Slave 

Information about space available on the per-port buffers comes out of a latch 
and is used to generate SThreadBusy information, which must be generated 
within the initial 10% of the OCP cycle (as described in "Level2 Timing* 1 on 
page 1 62). These signals are also used to generate SCmdAccept: if a particular 
port has room, a command on the corresponding thread is accepted. The 
correct port information is selected through a multiplexer driven by 
MThreadID at 50% of the clock cycle, making it easy to produce SCmdAccept 
by 75% of the OCP cycle. When the request group arrives at 60% of the OCP 
cycle, it is used to update the buffer status, which In turn becomes the 
SThreadBusy information for the next cycle. 

Master 

The master keeps information on what threads have commands ready to be 
presented (thread valid bits). When SThreadBusy arrives at 10% of the OCP 
clock, it is used to mask off requests, that is any thread that has its 
SThreadBusy signal set is not allowed to participate in arbitration for the 
OCP. The remaining thread valid bits are fed to thread arbitration, the result 
of which is the winning thread identifier, MThreadld. This is passed to the 
slave at 50% of the OCP clock period. It is also used to select the winning 
thread's request group, which is then passed to the slave at 60% of the clock 
period. When the SCmdAccept signal arrives from the slave, it is used to 
compute the new thread valid bits for the next cycle. 
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The request phase In Figure 39 assumes a non-exact thread busy model. The 
exact model shown in Figure 40 is similar, but SCmdAccept is tied off to 1, so 
any request issued to a non-busy thread is accepted In the same cycle by the 
slave. 



Figure 40 Multithreaded OCP Interface with threodbusy^exact 




Connections 

In multi-threaded, multi-initiator systems, it is frequently useful to associate 
a transfer request with a thread operating on a particular Initiator. Initiator 
identification can enable a system to restrict access to shared resources, or 
foster an error logging mechanism to identify an initiator whose request has 
created an error in the system. For devices where these concerns are impor- 
tant, the OCP extensions support connections. 

Connections are closely related to threads, but can have end-to-end meaning 
in the system, rather than the local meaning (that is, master to slave) of a 
thread. 

The connection ID and thread ID seem to provide similar functionality, so it 
Is useful to consider why the OCP needs both. A thread ID is an Identifier of 
local scope that simply Identifies transfers between the master and slave. In 
contrast, the connection ID is an identifier of global scope that Identifies trans- 
fers between a system initiator and a system target A thread ID must be small 
enough (that is, a few bits) to efficiently index tables or state machines within 
the master and slave. There are usually more connection IDs in the system 
than any one slave Is prepared to simultaneously accept Using a connection 
ID in place of a thread ID requires expensive matching logic in the master to 
associate the returned connection ID (from the slave] with specific requests or 
buffer entries. 
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Using a networking analogy, the thread ID Is a Ievel-2 (data link layer) 
concept, whereas the connection ID is more like a level-3 (transport/session 
layer) concept Some OCP slaves only operate at Ievel-2, so It doesn't make 
sense to burden them or their masters with the expense of dealing with level- 
3 resources. Alternatively, some slaves need the features of level-3 connec- 
tions, so in this case It makes sense to pass the connection ID through to 
them. 

A connection ID Is not usually provided by an initiator core on its OCP inter- 
face but is allocated to that particular initiator in the interconnect logic of the 
system. The connection ID is system- specific, not core-specific; only the 
system integrator has the global knowledge of the number of Initiators instan- 
tiated In the application, and what the requirements are in terms of 
differentiation. 

As an exception to that rule, if the global Interconnect consists of multiple 
hierarchical structures, a complete subsystem can be Integrated (including 
another interconnect with multiple embedded initiators). In that case, the 
OCP interface between the two Interconnects should implement the connld 
extension, so that the end-to-end meaning of that OCP field can be preserved 
at the system level. 

For a target core, the connid extension is Included when such features as 
access control, error logging or similar initiator-related features require Initi- 
ator Identification. 



OCP Specific Features 

Write Semantics 

The OCP-IP 1.0 Specification includes a Write command without a response. 
From the initiator standpoint, it completes once the request has been 
accepted, so follows a posted write model. The 2*0 release semantics specify 
whether a write is posted or not. A non-posted write model is preferred when- 
ever the originator of the request must be aware of the completion of its write 
command; An example Is clearing an Interrupt in a peripheral module using 
a write command. There the processor must be sure that the interrupt line 
has been effectively released before it can acknowledge the interrupt service 
In the chip-level interrupt controller. 

The 2.0 extension separates the concept of the posting semantics from the 
concept of responses on writes in the following ways: 

• A write with a response could have posted semantics in a system (so that 
a response is returned immediately) or it could have non-posted 
semantics (so that a response Is returned only after the write Is completed 
at the final target), 

• A write without a response normally has posted semantics and carries 
forward the OCP-IP 1.0 specification for backward compatibility. 
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• A write without a response can be assigned non-posted semantics by not 
accepting the command until the write has completed, but this is not 
recommended since it de-pipelines the OCP Interface. Since posting 
makes sense at a system level, adopting a delayed- SCmdAccept scheme 
can only be efficient locally, with no guarantee of the non-posting 
semantics at the system level. 

The writeresp_enable parameter controls whether writes have responses or 
not wri tenonpost_enable controls whether the interface supports the WriteN- 
onPost command, giving the initiator core the ability to launch two different 
types of writes. Table 25 summarizes the choices. 



Table 25 Write Parameters 




writenonpost.enable 




writeresp_enable 0 


1 


0 Simple posted write model, 

corresponds to OCP-IP1 .0 spec 


Illegal 


1 Initiator core hcs one flavor of 
writes (WR), system Integrator 
decides where to post the write 
requests 


Initiator core has two flavors of 
writes (WR and WRNP), system 
integrator decides where to 
post the two different write 
requests 



By separating whether writes have responses (writer esp_enable) from 
whether the core has control over where the responses are generated 
(writenonpost_enable), the OCP specification provides the following features: 

• The simple, posted model remains intact The simplest cores only 
implement WR, and need not worry about write responses. 

• Cores that can generate or use write responses should enable write 
responses, providing support for in-band error reporting on write 
commands. The read and write state machines are duplicated from the 
standpoint of flow control, producing a simpler design. Such cores would 
normally only implement the WR command. In this case, the system 
integrator is in control of where in the write path the write response Is 
generated, allowing a choice of the level of posting based upon 
performance and coherence trade-offs. 

• Cores that can distinguish between performance and coherence {really 
only CPUs and bridges) can enable WRNP to implement dynamic choice 
between WR and WRNP. The additional signaling gives the system 
integrator the dynamic information needed to choose the posting point as 
the CPU requests. The only practical difference between WR and WRNP at 
the protocol level is the expected latency between request and response. 
This permits some embedded CPUs to achieve high performance - 
particularly as interconnects become pipelined and posting buffers are 
needed. 
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When the writeresp_enable parameter Is enabled, responses are required 
for any write command Issued on the OCP, including WR WRNP, but also 
BCST and WRC. 

Use of the Broadcast command must be limited to specific category of designs 
(some interconnect designs may benefit from simultaneous update through 
distributed registers). It is not expected that standard cores support the 
command. 



Lazy Synchronization 

Most processors support semaphores through a read-modlfy-write type of 
Instruction and swap, test-and-set. etc. Using an OCP interconnect, these 
instructions are mapped onto a pair of OCP commands. A RDEX command 
sets a lock to the memory location, followed by a WR (or WRNP) command to 
release the lock. Hie system must ensure that no other thread will be granted 
access to that memory location between the RDEX and the unlocking WR 

Because the Write that clears the lock must immediately follow the ReadEx 
(on the same thread), only a limited number of operations can be performed 
by a processor between RDEX and WR Because competing requests to the 
locked location are also blocked from proceeding until the lock is unset, you 
could lock part of the interconnect for the duration of the RDEX-WR or WRNP 
pair. Such a mechanism, often referred to as locked synchronization, is effi- 
cient for handling exclusive accesses to a shared resource, but can result in 
a significant performance loss when used extensively. 

For these reasons, some processors use non-blocking instructions for sema- 
phore handling, breaking the atomicity of the exclusive read/write pair. For 
the processor, this allows other instructions to be executed by the processor 
between the read and write accesses. For the system interconnect, it allows 
requests from other threads to be inserted between the read and write 
commands. Referred to as lazy synchronization, this mechanism requires new 
read and write semantics, commonly known as LL/SC semantics, for Load- 
Linked and Store-Conditional. 

OCP-IP 2.0 support for lazy synchronization uses the ReadLinked, and Write- 
Conditional commands. A single OCP parameter rdlwrc__enable is set to l t to 
enable the commands. Because some processors might use both semantics 
(locked and lazy), the OCP Interface supports RDEX, RDL, WR{WRNP) and 
WRC. 

The system relies upon the existence of monitor logic, that can be located 
either in the system interconnect, or in the memory controller. The 
ReadLinked command sets a reservation tag in the logic, associating the 
accessing thread with a particular address. The WriteConditional command, 
being transmitted on the same thread, is locally transformed into a memory 
write access only if the reservation tag is still set when the command is 
received. As the tagged address Is not locked, the tag can be reset by 
competing traffic directed to the same location from other threads between 
RDL and WRC. 
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Consequently, the WRC command expects a response from the monitor logic, 
reflecting whether the write operation has been performed. To answer that 
requirement, OCP-IP 2.0 provides the value, FAJL for the SResp field (meaning 
that writeresp_enable Is on if rdlwrc_enable !s on). WRC is the only OCP-IP 
2.0 command that makes use of the FAIL code, though new commands in 
future revisions may. FAIL responses are frequently received in a system 
using lazy synchronization that operates normally. Do not confuse FAIL with 
5Resp=ERR, which effectively signals a system interconnect error or a target 
error. 

Both RDL and WRC commands assume a single transaction model and 
cannot be used in a burst. 

The semantics of lazy synchronization are defined in the specification section 
of this document (Parti). Some specific sequences resulting from the usage of 
the RDL and WRC semantics are: 

• A thread can issue more than one RDL before issuing a WRC, or issue 
more than one RDL without issuing WRC. Whether the subsequent RDL 
clears the reservation tag or sets a new one is implementation-specific, 
depending on the number of hardware monitors. At least one monitor per 
thread is required. 

• If a thread issues a WR or WRNP command to an address it previously 
tagged with a RDL command, the write access clears all reservation tags 
from other threads for the same address (but not Its own reservation tag). 

• If a thread issues a WRC without having issued a RDL, the WRC will fail. 

• If a thread issues a RDEX between the RDL and WRC, the RDEX is 
executed, sets the lock and waits for the corresponding write to clear the 
lock. RDL- WRC reservation tags will not be afiected by the RDEX. The WR 
or WRNP that clears the lock, also clears any reservation tag set by other 
initiators for the same address {with the same MAddr, MByteEn and 
MAddrSpace if applicable). 

Because competing requests of any type from other threads to a locked (by 
RDEX) location are blocked from proceeding until the lock is unset, a RDEX 
command being Issued between RDL and WRC commands, also blocks the 
WRC until the WR or WRNP command clearing the lock is issued. This favours 
RDEX-WR or WRNP sequence over RDL- WRC, in the sense that competing 
RDEX-WR or WRNP and RDL- WRC sequences will always result in having the 
RDEX-WR or WRNP sequence win. 

Incorrect use of the two synchronization mechanisms can result in deadlock. 
The sequence of commands shown in Figure 41 might result in a deadlock. In 
this example Processor 1 tries to release the semaphore using RDL- WRC 
commands. Processor 2 tries to acquire the semaphore using RDEX-WR or 
WRNP commands. The RDEX-WR or WRNP sequence always occurs between 
the RDL and WRC. Because the WR or WRNP clearing the lock in Processor2 
will also clear the reservation tag for Processor 1 , the RDL-WRC sequence will 
never succeed. Processor 1 will never be able to release the lock or Processor2 
to acquire it 
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Figure 4 1 Synchronization Deadlock 

Processor 1 uses RDL/WRC Processor 2 uses test-and-set 
to release the semaphore to acquire the semaphore 

get_sem1: 

RDL - geLsem2: 

RDEX 
WR(NP) 

WRC 




The deadlock depicted in Figure 41 is a result of bad programming in 
Processor 2, and is veiy unlikely to happen in a real application environment 
As shown in Figure 42, to achieve forward progress. Processor 2 should read 
the semaphore value and wait for the semaphore to be free before trying to 
retrieve it by issuing a RDEX-WR or WRNP. 

Figure 42 Correct Synchronization Sequence 



Processor 1 uses RDL/WRC 
to release the semaphore 



get_sem1: 
RDL 



WRC 




Processor 2 uses test and 
test-and-set to acquire the semaphore 



geLsem2: 
RD 



RDEX 
WR(NP) 




OCP and Endianness 

As described in "Endianness" on page 41, OCP is nearly endian-neutral. 
While OCP specifies a byte address on MAddr, the address must be aligned to 
the data width of the interface. Sub-word quantities are specified using one 
bit for each enabled byte in the transfer on MByteEn or MDataByteEn. 

While the bit ordering of OCP fields is consistently described in a little-endian 
fashion, this is conventional, where even big-endian systems tend to number 
their bits litUe-endlan, Similarly, the MByteEn numbering seems to imply a 
little-endian byte ordering, but is simply intended to maintain consistency* 
For example, MByteEn(mJ refers to the byte transferred on MData/ 
SDataI(8m+7):8ml {provided m < data width/8), regardless of the effective 
transfer endianness attributes. 
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If the master OCP and the slave OCP are the same data width, endianness 
does not matter Addresses, data, and byte enables must remain consistent 
across both interfaces, (There are exceptions, since packed sub-word data 
objects should be swapped if the endianness does not match, OCP does not 
cany the required signaling to determine sub-word sizes, so full-word trans- 
fers must be assumed.) 

Endianness problems arise as soon as one looks to connect a master and 
slave with different data widths. The narrow side has extra (non-zero) address 
bits, since its word- aligned addresses do not force as many bits to be zero. The 
wide side has extra byte lanes to cany its wider words. The association of the 
extra address bits (narrow side) with the extra byte lanes (wide side) specifies 
an endianness. 

To bridge interfaces that suffer from mismatched data widths, packing and 
unpacking is required. Data width conversion must make some assumptions 
about the correspondence between the MAddr least- significant bits and the 
MByteEn field. 

If the association maps the low-order byte lanes to lower addresses, the data 
width conversion is performed in a little-endian manner. If the association 
maps the high-order byte lanes to lower addresses, the data width conversion 
is performed in a big-endian manner. This operation is absolutely not an endi- 
anness conversion, but rather an endianness- aware packing or unpacking 
operation, so that the transaction endianness is preserved across the data 
width converter. 

There is no attempt to perform any endian conversion in hardware. Rather, 
the goal is to enable interconnects that are essentially endian-neutral, but 
become endian- adaptive to match the endianness of the attached entities. 
This Implies that the native endianness of an OCP core must be specified. 
OCP-IP 2.0 captures that property using the endian parameter, which can 
take four values: 

LITTLE 

Qualifies little-endian only cores 

BIG 

Qualifies big-endian only cores 
BOTH 

Qualifies cores that can change endianness: 

- Based upon an external input such as a CPU that statically selects Its 
endianness at boot time 

- Based upon an internal configuration register such as a DMA engine, 
that generates OCP read and write requests in accordance with the 
endianness of the target, as stated by the DMA programmer 

Cores that support dynamic endianness 
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NEUTRAL 

Qualifies cores that have no inherent endianness. Examples are simple 
memory devices that only work with full OCP- word quantities, or 
peripheral devices, the endianness of which can be controlled by the 
software device driver. 

While not supported by the OCP-IP 2.0 standard set of features, it is possible 
to define a dynamic endian- aware Interconnect using in-band information. By 
specifying the parameters reqinf o [for request packing / unpacking control), 
mdatainf o {for data packing / unpacking control when datahandshake is 
enabled), and respinf o (for response packing / unpacking control), the defi- 
nition of all these qualifiers is then platform-specific. 



Sideband Signals 

The sideband signals provide a means of transmitting control-oriented infor- 
mation. Since the signals are rarely performance sensitive, implementors are 
strongly encouraged to ensure that all sideband signals are driven stable very 
early in the OCP clock cycle; that is, that sideband outputs come directly out 
of core flip-flops. Sideband inputs should similarly be allowed to arrive very 
late in the OCP clock cycle; that is, sideband inputs should be registered 
almost immediately by the receiving core. 

Cores that do not implement this conservative timing may require modifica- 
tion to achieve timing convergence. 

Reset Handling 

Many systems are fully satisfied with a single reset signal applied to both the 
master and the slave on an OCP interface. Either the master or the slave can 
drive the reset, or a third entity, such as a chip level reset manager, can 
provide it to both master and slave. 

In some situations, it is more convenient for the master and slave to employ 
their own reset domains and communicate these internal resets to one 
another. The OCP interface Is unable to communicate until both sides are out 
of reset since the side still in reset may be driving undetermined values (X) on 
their OCP outputs and cause problems for the side that is already out of reset 
Examples of cases where this might arise are: 

• A core with multiple OCP interfaces that are connected to different 
interconnects, which are each in different reset domains, plus the core 
has its own internal reset domain. 

• Two connected interconnects with both acting as Initiators of transfers 
and each with their own reset domain. 

Adding a second reset signal to the interface allows each master and slave to 
have both a reset output and Input. The composite reset state for the OCP 
Interface is established as the combination of the two resets, so that either 
side (or both) asserting reset causes the interface to be in reset While in reset, 
the existing rules about the interface state and signal values apply. 
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Either MReseLn or SReset_n must be present on any OCP Interface. Compat- 
ibility between different reset configurations of master and slave interfaces Is 
shown in Table 26. 



Table 26 Reset Configurations 



Master 


sreset=l. 


sresetsO, 


sreset=1. 


Slave 


mreset=rO 


mreset=1 


mreset=l 


sresete), 
mreset=l 


Dual resets driven by the Single reset driven by 
same 3 rd party master 


Single reset driven by 
master (SReseLn 
Input tied off to 1) 


sreset=l. 
mreset=0 


Single reset driven by 
slave 


Incompatible 


Incompatible 


sreset=l, 
mreset=l 


Single reset driven by 
slave (MReseLn input 
tied off to 1) 


Incompatible 


Dual resets 



The rules describing this table can be stated as follows. 

• Either mreset or sreset or both must be set to 1 for each core. 

• The default (and only) tie-off value for MReset.n and SReset.n Is 1. 

• If mreset Is set to 1 for the master and mreset Is set to 0 for the slave, the 
reset configurations are incompatible. 

• If sreset is set to 1 for the slave and sreset is set to 0 for the master, the 
reset configurations are incompatible. 

Cores with a reset input are always Interoperable with any other core. Add a 
reset output if it Is needed by the core or subsystem to assure proper opera- 
tion. Typically this is because both sides need to know about the reset state 
of the other side, or because the overall system does not function properly if 
the core or subsystem is in reset, while the OCP interface is not In reset. 

Compatibility with OCP-IP 1.0 

OCP-IP 1.0 cores that have a reset input or output can be converted to OCP- 
IP 2.0 cores by renaming the Reset.n pin in the core's RTL conf file without 
touching the actual HDL source of the core. The new name depends on 
whether the reset is an input or output and whether the core is a master or 
slave. 

In the very unlikely situation of an OCP-IP 1.0 core lacking a reset input or 
output, the conversion to OCP-IP 2.0 Is achieved by the addition of a dummy 
reset Input pin that is not used Inside the core. 
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Debug and Test Interface 

There axe three debug and test interface extensions predefined for the OCP: 
scan, clock control, and IEEE 1 149. The scan extension enables Internal scan 
techniques, either In a pre-designed hard-core or end user inserted into a 
soft-core. Clock Control extensions assist in scan testing and debug when the 
IP core has at least one other clock domain that is not derived from Clk. The 
IEEE 1 149 extension is for interfacing to cores that have an IEEE 1 149. 1 test 
access port built-in and accessible. This is primarily the case with cores, such 
as microprocessors, that were derived from standalone products. 

These three extensions along with sideband signals (flags) can yield a highly 
debuggable and testable IP core and device. 

Scan Control 

The width and meaning of the Scanctrl field Is user-defined. At a minimum 
this field carries a signal to specify when the device is in scan chain shifting 
mode. The signal can be used for the scan clock if scan-clock style flip-flops 
are being used. When this is a multi-bit field, another common signal to cany 
would be one specifying the scan mode. This signal can be used to put the IP 
core into any special test mode that is necessaiy before scanning and appli- 
cation of ATPG vectors can begin. 

Clock Control 

The clock control test extensions are Included to ease the integration of IP 
cores into full or partial scan test environments and support of debug scan 
operations in designs that use clock sources other than Clk. 

When an external clock source exists (for example, non-Clk derived clock), the 
ClkByp signal specifies a bypass of the external clock. In that case theTestClk 
signal usually becomes the clock source. The TestClk toggles in the correct 
sequence for applying ATPG vectors, stopping the internal clocks, and doing 
scan dumps as required by the user. 
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To provide core timing information to system designers, characterize each 
core into one of the following timing categories: 

• LevelO identifies the core interface as having been designed without 
adhering to any specific timing guidelines* 

• Levell timing represents conservative interface timing. 

• Level2 represents high performance Interface timing. 

One categoiy is not necessarily better than another. The timing categories are 
an indication of the timing characteristics of the core that allow core designers 
to communicate at a very high level about the interface timing of the core. 
Table 27 represents the inter-operability of two OCP interfaces. 

Table 27 Core Interface Compatibility 





LevelO 


Levell 


Level2 


LevelO 


X 


X 


X 


Levell 


X 


V 


V 


Level2 


X 


V 


V 



X no guarantee 

V guaranteed inter-operability with possible performance loss (extra 
latency) 

V* high performance inter-operability but some minor changes may be 
required 

The timing guidelines apply to dataflow and sideband signals only. There is 
no timing guideline for the scan and test related signals. 
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Timing numbers are specified as a percentage of the minimum supported 
clock-cycle (at maximum operating frequency). If a core is specified at 
100MHz and the c2qtime is given as 30%, the actual c2qtime is 3ns. 



LevelO Timing 

LevelO timing indicates that the core developer has not followed any specific 
guideline in designing the core interface. There is no guarantee that the inter- 
face can operate with any other core interface. Inter-operability for the core 
will need to be determined by comparing timing specifications for two inter- 
faces on a per- signal basis. 



Level 1 Timing 

Level 1 timing indicates that a core has been developed for minimum timing 
work during system integration. The core uses no more than 25% of the clock 
period for any of its signals, either at the input (setup time) or at the output 
(outputtime). A core interface in this category must not use any of the combi- 
national paths allowed in the OCP interface. 

Since inputs and outputs each only use 25% f 50% of the cycle remains avail- 
able. This means that a Level 1 core can always connect to other Level 1 and 
Level2 cores without requiring any additional modification. 



Level2 Timing 

Level2 timing indicates that a core interface has been developed for high 
performance timing. A Level2 compliant core provides or uses signals 
according to the timing values shown in Table 28. There are separate values 
for single-threaded and multi-threaded OCP interfaces. The number for each 
signal indicates the percentage of the minimum cycle time at which the signal 
!s available, that is the outputtime at the output Setuptime at the input is 
calculated by subtracting the number given from the minimum cycle time. For 
example, a time of 30% indicates that the outputtime is 30% and the setup- 
time is 70% of the minimum clock period. 

In addition to meeting the timing indicated in Table 28, a Level2 compliant 
. core must not use any combinational paths other than the preferred paths 
listed in Table 29. 

There is no margin between outputtime and setuptime. When using Level2 
cores, extra work may be required during the physical design phase of the 
chip to meet timing requirements for a given technology/library. 
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Table 28 Leve!2 Signal Timing 



Signal 


Single-threaded 
Interface % 


Multi-threaded 
Interface % 


Control, Status 


25 


25 


ControiBusy. StatusBusy 


10 


10 


ControlWr. StctusRd 


25 


25 


Datahandshake Group 
(excluding MDataThreodlD) 


30 


60 


MDataThreodID 


n/a 


50 


MRespAccept 


50 


75 


MThreadBusy 


10 


10 


MThreadID 


n/a 


50 


Request Group 
Cexcludlng MThreadID) 


30 


60 


MReset_n, SReset_n 


10 


10 


Response Group (excluding SThreadID) 


30 


60 


SCmdAccept 


50 


75 


SDataAccept 


50 


75 


SDataThreadBusy 


10 


10 


SError. SFlog, SInterrupt. MFlag, MError 


40 


40 


SThreodBusy 


10 


10 


SThreadID 


n/a 


50 


Table 29 Allowed Combinational Paths for Level2 Timing 




Core From 


To 




Master SThreodBusy 


Request Group 




SThreodBusy 
SDataThreadBusy 


Datahandshake Group 


Response Group 


MRespAccept 




Slave MThreadBusy 


Response Group 




Request Group 


SCmdAccept and 
SDataAccept 


Datahandshake Group 


SCmdAccept and 
SDataAccept 
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This chapter describes checks (performed by the ocpcheck tool) to determine 
compliance with the OCP protocol and is Intended to help in the development 
of verification suites and checkers in various verification environments. The 
checks within this chapter assume that the configuration being tested is 
valid. For more information about the ocpcheck tool, see the Core Preparation 
Guide. 

Checks need to be applied with varying frequency; cycle-based checks on 
every cycle, phase-based checks across each phase of an OCP transfer. 
Transfer-level checks verify correct sequencing among grouped OCP phases. 
Transaction-level checks verify that protocol requirements for grouped trans- 
fers are not violated. 

Make all OCP checks synchronous with respect to the rising edge of the OCP 
clock so that signal values are analyzed at the rising edge of the OCP clock. 
Check any complex hierarchy elements that span multiple cycles from data 
collected on the rising edge of the clock. 

Checks of any sort should not be performed until either MReseLn or SReset_n 
becomes 0. Checks should also not occur if either signal is 0. The only checks 
that need not comply with this rule are the checks for X or Z on MReset_n and 
SReset_n. These checks are performed once either signal transitions to 0. A 
second exception is the check to see that MReset_n and SReset_n are held to 
0 for sixteen cycles. 
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Signal Testing 

Signal testing checks listed in Tables 30-33, verify that the values of the OCP 
signals are valid. Whenever a signal Is valid at the rising edge of the OCP clock 
It should not have a value of X or Z. 



Table 30 Signal Checks Every Cycle for XorZ 



Signal 


Enabling Parameter Expression 


ControlBusy 


controibusy = 1 


ControlWr 


controlwr == 1 


MCmd 




MOataVolid 


datahandshake — 1 


MError 


merror == 1 




mrp^fit — — 1 


MThreadBusy 


mthreadbusy ==s 1 


SDotaThreadBusy 


sdatathreodbusy == 1 


SError 


serror » 1 


SInierrupt 


Interrupt == 1 


SReset-n 


sreset — 1 


SResp 


resp =« 1 


StatusBusy 


statusbusy == 1 


StatusRd 


statusrd =* 1 


SThreadBusy 


sthreadbusy =» 1 


Table 31 Signal 


Checks During Request Phases 


Signal 


Enabling Parameter Expression 


MAddr 


addr== 1 


MAddrSpace 


addrspoce == 1 


MAtomlcLength 


atomlclength == 1 


MBurstlength 


burstlength == 1 


MBurstPreclse 


burstpreclse = 1 


MBurstSeq 


burstseq == 1 


MBurstSlngleReq 


burstslnglereq « 1 


MByteEn 


byteen = 1 


MConniD 


connld — 1 


MReqLast 


reqlast == 1 


MThreadlD 


threads > 1 


SCmdAccept 


cmdaccept == 1 
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Table 32 Signal Checks During Datohandshake Phcse 
Signal Enabling Parameter Expression 



MDataByteEn 
MDataLast 
MDataThreadID 
SDataAccept 



mdatabyteen 
dataiast == 1 
threads > 1 
dataaccept == 1 



Table 33 Signal Ch ecks During Response Phase 
Signal Enabling Parameter Expression 



MRespAccept 

SRespLast 

SThreodID 



respaccept = 
respiast = 1 
threads > 1 



1 



The signals listed below do not need to be checked for X or Z since they have 
no architecturally defined encodings. 



Control 

MDatalnfo 

MReqlnfo 

SDatalnfo 

SRespInfo 

Test 



MData 

MFlag 

SData 

SFlag 

Status 



Signal Refraction Testing 

If a phase lasts more than one cycle checks need to be performed on some 
signals belonging to the corresponding group to ensure that they have not 
changed value from the starting cycle of the request phase. 



Table 34 Signal Checks for Retraction During Request Phase 



Signal 



Enabling Parameter Expression 



MAddr 

MAddrSpace 

MAtomlcLengtft 

MBurstLength 

MBurstPrecise 

MBurstSeq 

MBurstSingleReq 

MByteEn 

MCmd 

MConnID 



addr — 1 
addrspace == 1 
atomfctength =s 1 
burstiength =« 1 
burstpreclse — 1 
burstseq 1 
burstsinglereq =- 1 
byteen — 1 

connid == 1 
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Signal Enabling Parameter Expression 

MData (mdata — 1 ) && (datahandshake == 0) and 

MCmd Is a write type operation 

MDatalnfo (mdatainfo == 1)&& (datahandshake == 0) 

MReqlnfo req!nfo==l 

MReqLast reqlcst — 1 

MThreadiD threads > 1 

Table 35 Signal Checks for Retraction During Datahandshake Phase 

Signal Enabling Parameter Expression 

MData (mdata == I) && (datahandshake == 1) 

MDataByteEn nadatabyteen 

MDatalnfo (mdatainfo == 1 )&& (datahandshake = 1 ) 

MDataLcst datalast 1 

MDataThreadID threads > 1 

Table 36 Signal Checks for Retraction During Response Phase 

Signal Enabling Parameter Expression 

SData (sdata 1) and MCmd is a read type operation 

SDatalnfo sdatainfo == 1 

SResp resp — 1 

SRespInfo resplnfo— 1 

SResplast respicst == 1 

SThreadID threads > 1 



Phase-Based Checks 

Phase-based checks should be performed on each of the different phases. The 
checks should be Independent of events at the transfer and transaction levels, 
and only examine an Individual phase. 

Request Phase Checks 

The following checks must be performed during the request phase: 

• For eveiy cycle, verify that MCmd is not an Illegal command. Illegal 
commands are those lacking an enabling parameter on the OCP Interface, 
For example WRNP Is not valid if writenonpost_enable and 

writ ere sp.enable are not enabled. Refer to Table 19 on page 47 for details 
on how to determine which commands are not enabled on an OCP 
connection* 

• Any single request must have a MReqLast value of 1* 
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• When threads is greater than 1, check MThreadID to determine If the 
threads parameter Is within the specified range. 

• Check If a request Is made to a specific thread that has SThreadBusy 
asserted. If sthreadbusy_exact is set to 1, an error should be logged. 

• If f orce.aligned Is enabled the byte enable pattern on MByteEn must 
represent an aligned subword that Is a power-of-two bytes In size. 

• MAddr must be OCPword aligned. The lowest order bits of MAddrmay not 
be OCP word aligned as long as they are zero. 

• MBurstSeq can not use the reserved value 0x7. 

Dafahandshake Phase 

The following checks must be performed when datahandshake is enabled on the 
OCP interface: 

• Every datahandshake phase must have a matching request phase. 

• Check that MDataThreadID is within a valid range, that Is, 
MDataThreadID < threads. 

• Check if a datahandshake is made to a thread with SDataThreadBusy 
asserted. If sdatathreadbusy_exact is set to 1, an error should be logged, 

• If f orce_aligned is enabled the byte enable pattern MDadaByteEn must 
represent an aligned subword that is a power-of-two bytes in size. 

Response Phase 

Perform the following checks for all response phases: 

• Eveiy response phase must have a corresponding request phase, 

• Check that STTireadlD is within a valid range, that Is, SThreadID < 
threads. 

• Check if a response Is sent to a thread with MThreadBusy asserted. If 
mthreadbusy_exact Is set to 1, an error should be logged. 



Transfer- Based Checks 

Every transfer should be checked for the following: 

• A datahandshake phase cannot begin before the associated request phase 
begins, but can begin in the same Clk cycle. 

• A datahandshake phase cannot end before the associated request phase 
ends, but can end in the same Clk cycle. 

• A response phase cannot begin before the associated request phase 
begins, but can begin in the same Clk cycle. 
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• A response phase cannot end before the associated request phase ends, 
but can end In the same Clk cycle. 

• If there Is a datahandshake phase and a response phase, the response 
phase cannot begin before the associated datahandshake phase begins, 
but can begin In the same Clk cycle. 

• If there is a datahandshake phase and a response phase, the response 
phase cannot end before the associated datahandshake phase ends, but 
can end In the same Clk cycle, 

• Check that response Is allowed for the given MCmd, 

• For a single transfer requiring a datahandshake phase, If MDataLast is 
configured it must be asserted. 

• For a single transfer requiring a response phase, if SRespLast is 
configured it must be asserted. 

The ordering rules also apply to transfers within a single request/multiple 
data (SRMD) burst. For write SRMD burst transfers all the datahandshake 
phases of a burst match to one common request phase. If writeresp.enable is 
set to 1, all of the datahandshake phases of a burst also match to one 
common response phase. For read SRMD burst transfers all the response 
phases of a burst match to one common request phase. 

Check for incomplete transfers at the end of simulation. If a transfer has not 
started one of Its phases or completed one of its phases, report the incomplete 
transfers that are detected. 

For multi-threaded OCP interfaces with datahandshake set to 1 and sdatath- 
readbusy set to 0, check that the order of the datahandshake phases follows 
the order of the requests phases across all threads. 



Transaction-Based Checks 

Check completed transfers to determine if there are protocol violations across 
multiple transfers. Test all burst and RDEX transactions to ensure that no 
transfers are missing and that each transfer is complete. In the event an 
incomplete transaction Is detected at the end of simulation, it may be 
adequate to report only the starting times of the detected incomplete 
transactions. 



Burst Checks 

When the transaction consists of one or more transfers with the first transfer 
having an MBurstLength >1, perform the following checks: 

• Check that RDEX, RDL, and WRC are not part of a burst. It Is sufficient 
to just check the starting transfer of the burst. 
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• MCmd, MConnID, MAddrSpace, MBurstPrecise, MBurstSlngleReq, 
MBurstSeq, MAtomicLength, MReqlnfo and SRespInfo must remain 
constant across all transfers of the burst This Is true for both precise and 
imprecise bursts, 

• When MBurstSlngleReq Is set to 0, for the last transfer of the burst, 
MReqLast must be 1. All other burst transfers must have a MReqLast of 
0. When MBurstSlngleReq Is set to 1, MReqLast must be 1. 

• MBurstLength must remain constant across all transfers of a precise 
burst. 

• MDataLast should only be 1 for the last transfer of the burst. All other 
burst transfers must have a MDataLast value of 0, 

• For the last transfer of a burst. SRespLast must be 1, All other burst 
transfers must have a SRespLast value of 0. 

• If burstseq_dfltl_enable is 0 the master must not Issue DFLT1 bursts. 
This can be determined by checking the starting transfer of the burst 

• If burstseq_dflt2_enable Is 0 the master must not issue DFLT2 bursts. 
This can be determined by checking the starting transfer of the burst 

• If burstseq_incr_enable is 0 the master must not issue 1NCR bursts. This 
can be determined by checking the starting transfer of the burst 

• If burstseq_stnrL.enable is 0 the master must not issue STRM bursts. This 
can be determined by checking the starting transfer of the burst 

• If burstseq_unkn_enable is 0 the master must not issue UNKN bursts. This 
can be determined by checking the starting transfer of the burst 

• If bursts eq_wrap_enable is 0 the master must not Issue WRAP bursts. This 
can be determined by checking the starting transfer of the burst 

• If burstseq__xor„enable Is 0 the master must not Issue XOR bursts. This 
can be determined by checking the starting transfer of the burst 

• WRAP and XOR burst sequences must only occur with precise bursts. 

• WRAP and XOR must always have a power of two burst length. Checking 
MBurstLength of the first transfer Is sufficient for this check. 

• Verify the MAddr sequence is correct for XOR bursts. 

• For incrementing bursts, when burst_aligned Is enabled, the total burst 
size must be a power of two. 

• When burst_aligned Is enabled, Incrementing bursts must have their 
starting address aligned with the total burst size. 

• When burst_aligned is enabled, Incrementing bursts must be issued as 
precise bursts. 

• Each transfer of an incrementing burst must increment MAddr by the 
OCP word size. 
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• For incrementing bursts MAddr must never wrap around the address 
space of the OCP interface. 

• Streaming bursts must have the same MAddr across all transfers of the 
burst and MByteEn must be constant 

• Verily that the address sequence Is correct for WRAP bursts. 

• If reqdata_together is set to l f the request and data must arrive together. 

• For precise bursts the transfer count must match MBurstLength. 

Read Exclusive Transaction Check 

Perform the following checks on RDEX transactions: 

• On the completion of a ReadEx transfer, check that the next transfer on 
the same thread Is a WR or WRNP to the same address (MAddr and 
MAddrSpace), and byte enable pattern (MByteEn) as the ReadEx 
transaction. 

• Check that the WR/WRNP following the RDEX has a MBurstLength of 1 



Sideband Checks 

The checks In this section apply to the sideband signals. 

Reset Checks 

The following checks must be performed on the reset signals: 

• lf MReset_n is asserted, it must remain asserted for at least 16 cycles. 

• If SReset.n is asserted. It must remain asserted for at least 16 cycles. 

Control Checks 

The following checks must be performed on the control signals: 

• Control must be held steady the first cycle after reset is deasserted. 

• The ControlWr signal cannot be asserted in the cycle following a reset 

• The Control signal can not change more than once every other cycle. 

• The ControlWr signal must be asserted when the Control signal changes, 

• The Control signal may not change if the ControlBusy signal is asserted. 

• The ControlWr signal can not remain asserted for two consecutive cycles. 

• The ControlWr signal can not be asserted if ControlBusy is active. 
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• ControlBusy can only be asserted In a cycle after ControlWr Is asserted or 
reset transitions to inactive. 

Status Checks 

The following checks must be performed on the status signals: 

• The StatusRd signal is active for no more than one clock cycle. 

• The StatusRd signal is not asserted while StatusBusy is asserted. 
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To make It easier for the system integrator to choose cores and architect the 
system, an IP core provider should document a core's performance character- 
istics. This chapter supplies a template for a core performance report on 
page 180, and directions on how to fill out the template. 



Report Instructions 

To document the core, you will need to provide the following information: 

1. Core name. Identify the core by the name you assigned. 

2. Core ID. Specify the precise identification of the core inside the system- 
on-chip. The Information consists of the vendor code, core code, and 
revision code. 

3. Core is/is not process dependent Specify whether the core is process- 
dependent or not. This Is Important for the frequency, area, and power 
estimates that follow. 

If multiple processes are supported, name them here and specify 
corresponding frequency/ area/power numbers separately for each core if 
they are known, 

4. Frequency range for this core* Specify the frequency range that the core 
can run at If there are conditions attached, state them clearly. 

5. Area. Specify the area that the core occupies. State how the number was 
derived and be precise about the units used. 

6* Power estimate. Specify an estimate of the power that the core consumes. 
This naturally depends on many factors, Including the operations being 
processed by the core. State all those conditions clearly, and if possible, 
supply a file of vectors that was used to stimulate the core when the power 
estimate was made. 
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7. Special reset requirements. If the core needs MReset_n/SReset_n asserted 
for more than the default (16 OCP clock cycles) list the requirement 

8. Number of Interfaces. 

9. Interface information. For each OCP Interface that the core provides, list 
the name and type. 

The remaining sections focus on the characteristics and performance of 
these OCP interfaces. 

• For master OCP interfaces: 

a. Issue rate {per OCP cycle for sequences of reads, writes, and 
interleaved reads/writes). State the maximum issue rate. Specify 
issue rates for sequences of reads, writes, and Interleaved reads 
and writes. 

b. Maximum number of operations outstanding (pipelining support). 
State the number of outstanding operations that the core can 
support: is there support for pipelining. 

c. If the core has burst support, state how It makes use of bursts, 
and how the use of bursts affects the issue rates. 

d. High level flow-control. If the core makes use of high-level flow 
control, such as full/empty bits, state what these mechanisms are 
and how they affect performance. 

e. If multiple threads are present, explain the use of threads. 

f. Connection ID support Explain the use and meaning of 
connection information. 

g. Use of side-band signals. For each sideband signal {such as 
SInterrupt, MFlag) explain the use of the signal. 

h. If the OCP Interface has any implementation restrictions, they 
need to be clearly documented. 

• For slave OCP interfaces: 

a. Unloaded latency for each operation (in OCP cycles). Describe the 
unloaded latency of each type of operation. 

b. Throughput of operations {per OCP cycle for sequences of reads, 
writes, and interleaved reads/writes). State the maximum 
throughput of the operations for sequences of reads, writes, and 
interleaved reads and writes. 

c. Maximum number of operations outstanding (pipelining support). 
State the number of outstanding operations that the core can 
support, i.e. Is there support for pipelining, 

d. Burst support and effect on latency and throughput numbers. If 
the core has burst support, state how it makes use of bursts, and 
how the use of bursts affects the latency and throughput numbers 
stated above. 
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e. High level flow-control. If the core makes use of high-level flow 
control, such as full/empty bits, state what these mechanisms are 
and how they affect performance. 

f. If multiple threads are present, explain the use of threads. 

g. Connection ID support. Explain the use and meaning of 
connection Information. 

h. Use of side-band signals. For each sideband signal (such as 
Slnterrupt, MFIag) explain the use of the signal. 

1. If the OCP Interface has any Implementation restrictions, they 
need to be clearly documented. 

• For every non-OCP interface, you will need to provide all of the same 
information as for OCP Interfaces wherever it Is applicable. 
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Sample Report 



1. Core name 


flcshctrl 


2. Core identity 
Vendor code 
Core code 


Qx50c5 
0x002 

UA 1 


o. v^uit? to/19 nui piULcSa 

dependent 


Mot 


4. Frequency range for this core 


*1 OOMhz with NECCBC9-VX library 


5. Area 


4400 gates 

zinpuT nainu equivaiem gates 


o. rower esTimai© 


not available 


7. Special reset requirements 




8. Number of Interfaces 


2 


9. Interface Information: 
Name 
Type 


ip 

slave 


For master OCP Interfaces: 




a. Issue rate (per OCP cycle 
for sequences of reads, 
writes, and Interleaved 
reads/writes) 




b. Maximum number of 
operations outstanding 
fnlrspftninn mnnrft 




c Effect of burst suDDort on 
Issue rates 




d. High level flow-control 




e. Use of threads (if any) 




f. Use of connection 
Information 




g. Use of side-band signals 




h. Implementation restrictions 





I 
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For slave OCP Interfaces: 




a. Unloaded latency for each 
operation (In OCP cycles) 


Register read or write: 1 cycle. The flash read takes SBFUAA 
(read access time). Can be changed by writing 
corresponding register field of emem configuration register. 
The flash write operation takes about 2000 cycles since It 
has to go through the sequence of operations - writing 
command realsf er. readlna the status reaister twice 


b, Throughput of operations 
(per OCP cycle for 
sequences of reads, writes, 
and Interleaved reads/ 
writes) 


No overlap of operations therefore reciprocal of latency. 


c. Maximum number of 
operations outstanding 
(pipelining support) 


No Dlaellnlna suDnort 


d. Effect of burst support on 
latency and throughput 
numbers 


No burst support. 


e. Hfgh level flow-control 


No high-level flow-control support. 


f. Use of threads (if any) 


No thread support. 


g. Use of connection 
Information 


No connection information support. 


h. Use of side-band signals 


Reset.n, Control. SError, Control Is used to provide additional 
write protection to critical blocks of flash memory. 
SError is used when an Illegal width of write Is performed. 
Only 16 bit writes are allowed to flash memory. 


1. Implementation restrictions 




For every non-OCP interface 
Provide all of the same 
Information as for OCP 
Interfaces wherever it is 
applicable. 


Hitachi flash card HN29WT800 

Only 1 flash ROM part Is supported, therefore the CE.N is 
hardwired on the board. 

The ready signal RDY_N. is not used since not all parts 
support it. 

For the BYTEJM signal, only 16-bit word transfers are 
supported 



OCP-IP Confidential 



ISO Open Core Protocol Specification 



Performance Report Template 

Use the following template to document a core. 



1. Core name 



2. Core identity 
Vendor code 
uore coae 
Revision code 




3. Core Is/is not process 
dependent 




4. Frequency range for this core 




5. Area 




6. Power estimate 




7. Special reset requirements 




8. Number of Interfaces 




O Intorfnr*© lnfr*irmntforv 

T* 11 HUllUVt? U il\J\ 1 1 lUltUl It 

Name 
Type 




For master OOP Interfaces: 




a. Issue rate (per OCP cycle 
for sequences of reads, 
writes* and interleaved 
reads/writes) 




U. iVJUAll MUI 11 1 lUrifk/ol QT 

operations outstanding 
(pipelining support) 




c. Effect of burst support on 
latency and throughput 
numbers 




d. High level flow-control 




e. Use of threads (if any) 




f. Use of connection 
Information 




g. Use of side-band signals 




h. Implementation restrictions 
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For sJave OCP Interfaces: 




a. Unloaded latency for each 
nnprntton fin OCP pvMps^ 




b. Throughput of operations 
(per OCP cycle for 

otrv^Uol iuUt> Ul lcUU9 ( Willed* 

and interleaved reads/ 
writes) 




/■» fv/1n ylrni im ni imhor of 

IVIUAll 1 l\JI 1 1 t IUI 1 IUt;l VJt 

operations outstanding 
(pipelining support) 




d. Effect of burst support on 
latency and throughput 
numuers 




©, nign levei now-coniroi 




i. use oi mrecas qit any} 




g. Use of connection 
Information 




h. Use of side-band signals 




1. implementation restrictions 




For every non-OCP Interface 
Provide all of the same 
information as for OCP 
interfaces wherever it is 
applicable. 
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A Ihreaa is e path ot execution through a program. Single threaded programs have one path of execution, and multi-threaded programs have two or 
more paths ot execution. Single threaded programs can perform only one task at a time, and have to finish each task in sequence before they can 
start another. For most programs, one thread of execution is at) you need, but sometimes ti makes sense to use multiple threads rn a program to 
accomplish multiple simultaneous (asks. 

For example, a multi-threaaed math progiam can lei the user set parameters for 8 new calculation whiie a previous calculation computes. Or a 
muUi- threaded word processor can let the user open a new document while a large lite saves or spools to the primer. Ano sometimes, as you wHi 
see in this article, a multi-threaded approach is necessary when you need e method to execute in a continuous loop in one thread and another 
thread to do something else like paint the display between loop iterations. 

This article describes multi-threaded programming by presenting an example slide show applet. The 
images for the slide show applet are thumbnails ol paintings by Claude Monet downloaded from a 
public web site. If Claude Monet were ellve today, the thumbnails and slide show applet might very 
welt be available from his own web site so prospective buyers can view his latest works and make 
electronic purchases. 





Atl single or mufti-thread programs execute in their own thread created and staned by the underlying Java VM 1 . The Java VM also creates a 
threads to help manage single or multi-threaded program execution. For example, the Java VM starts the F:.n& I i *er thread to execute an 
method before the object ts garbage collected, and starts the wvt i- ■ ..*n i ?wj~ t v- o thread to call an objects event handling methods such a 
bcriiTiP-is f -iraifc-5 and wiarSfjvCiaF ir.y. Because the Java VM spawns threads to handle the execution of a program, you might say that 
is s multi-threaded program. 




Normally, you do not have to concern yourself with threads crested by the Java VM to manage your program execution. As a developer, yoi 
is to determine whether your program works best single threaded or mutti- threaded, and then design and implement it accordingly. In mekini 
should take into account that spawning additional threads carries overhead by consuming extra memory and processor resources. But somi 
threaded approach is the best way to go so the user does not have to wait too long for a task to complete before starting another, or as in th 
show applet, for the program to work at all. 



Running the Slide Show Applet 

The slide show applet downloads three thumbnail paintings by Claude Monet end draws them one-by-one on the applet's panel. The 
thumbnail paintings are stored on a Web site and the slide show applet accesses them by their URL. 

To run the slice show applet, get the Slide Show .java class file and the Java. policy security policy file. Compile the i-rh^r-v. j 
cless file ano create a : " : ::jfc*> .h:^u file met looks Nke this: 



Slide One 




Use the applet viewer too' to run the applet as follows: 



Note: To run an applet written with Java 2 APIs in a browser, the browser must be enabled tor the Java 2 platform. II your browser is not enabled for the Java 2 Platform, you hf 
use the the applet viewer tool to run the applet or install Java Plug-In. Java Plug-In lets you run applets on Web pages under the 1.2 version of the Jeve VM instead ot the Web 
browser's default VM. For information on getting setup, see Chapter 9 "Deploying the Auction Application" in Advanced Programming for the Java 2 Platform. 



How the Threaded Applet Works Slide Two 

The slide show applet executes in its own thread and spawns a second thread to retrieve images from en image array, retrieve 
captions trom a text array, one call the r-^inv method to initiate drawing th* image and caption text. The actual drawing of the 

image end text is handled by an event thread started by the Java VM. 

Every thread has a name, so you can tell which th/eed is doing what by retrieving the current thread and getting its name with the wet wans method m the Th. class. When you create 
program, you can supply an optional name, and it you do not supply a name, the Java VM provides a default name that follows the following naming convention: "Phr^si- ?Mr e i , an 
createo by the Java VM have names too. as you will see in the sample run below. 
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Slide Show Sample Run 

The slide snow applet uses the and 3yri -sc. ...vui; i: methods to show which threod is 

executing. Below is a sample slrde show applet run that goes through all the applet's lite cycle methods. 

As you can see in the sample run, the i.v. r , su>vl, etvp. and v.:cy lite cycle methods execute in 

!-.■.;■-; ■-; . . . The 7 « . j method executes in the ? «j thread, and gets caned atter 

the : i ; thread is created and started in the applet's start method. The Tia*; thread retrieves images 
ana captions trom their arrays and calls the vh;^ ir.t method to initiate drawing to the applet's panel. The 
applet's \ and methods do the actual drawing and execute in the awi ■■ Ev* ~r. <:^i -(.• thread 
oecause updating and painting are panel events. 



New threads are spawned from threads that are already running. The Java VM spawns t>.: t;.pit:i.-^ j .i : ";a.*<. eno .-v.*. r-evMitv-utue- & to handle applet execution 
and panel events, ana l :- ; r : > 1 i - .S i irttiShw ■: i & spawns the Ti. ;so-i thread. The spawning ot the Tir.-er thread is what makes this program multithreaded. 



Why Use The Timer Thread? 

On the surface, it might seem like the applet has enough threads without creating the Tire? thread. After all. the applet's r. ; method running in t.h: ea ^ &i-pi bt- 

:•]'■. i . - can retrieve the images and text and call r in*;, and the cr- ":&t.c- and nt i r,r methods running in the v*^ v-.-^n* i^e.- 0 thread can do the rendering. Right? , 

Well, not realty. 

The browser's VM calls into ... :x, start. a ! ;op. and etas trey and expects them to return after doing whatever it is they have to oo. It you change the applet so i nit or a tare or e 
method called by =. . or .= ; : ; retrieves the imeges and text, the method will execute forever, never return, and put the applet in a deadlocked state. When that happens the only way 
to stop the applet is to issue a kill, interrupt, or break signal from the command line. The ristr thread is needed so i n J.r. or £ ■ te z. - can return and let the applet paint. 

Threaded Applet Anatomy 

The SlideShow applet implements the following methods: 
Ute Cycle methods: 




c-;si.i:<;y 

Thread -related methods: 




Drawing-related methods: 



Note: This section describes the slide show applet in terms of threads and how the applet's panel is updated with new images and captions. If you need to brush 
up on applet basics, see the applets lesson in Essentials of the Java Programming Language: A Hands -On Guide. 



Initializing the Applet 

The : method creates the sitde show dispiey and arrays to hold the images and caption text. The images are downloaded Irom a public Web site, so a URL ctass provides the URL 
tor the the images. This method calls the t?nie&<5 method, which creates the Tiir.«i: threed and leaves H in a paused state waiting to be notified to begin execution. 



K'r.. ^jp f . ions j r 



:; t-.- ■' - i C J 0 u ;'ifc K r. e. r * } ; 
n:;t;. .tEHTEF J : 



http://java.sunxom/jsp_uUls/PrimPage,isp?uri=http%3A%2F%2Fjava.sun.coin%2Fdevelo... 5/20/2005 



Creating a Threaded Slide Show Applet 



Page 3 of 6 



The i:-. i r.rM • implementations gets the name ol the current thread and prints that name to the command line. Tne sample run above shows that at this point in t 

execution me current thread is the apptei thread. 



Starting the Thread 

The Fi hrl.T'r.r. *..!.: method is ca)*eo once when me applet is first initialized to create viiwTi.-r*fca. initialize variables, and implement v ->?■ ■ * : behavior. The thread remains in exu 
stopped in the applet's - > method. 



Fut-.;iv- v.% 



The line \ : r.*-i i ■* ± . : ^. : ; : « : ; . ; i . \ - t i p.* : * j means create e thread named Tiro-:: and use t h i £ object as Its ta rget nmnaWe . A target runnable is an object of type Harm 

method implementation. So what you are really saving is when the ?i s*sr thread starts, execute the run method Implementation in i.r lk (the j= ; :«-.' r ^;:*0 object 

The call to tiyi«;-: : :.i: <?*..: i ; on the next line enlivens the T-lb*:;: thread by calling the run method In its target runnable. A thread remains alive until the r-jn method returns. 

The .:. i i d^shtA- dass uses an inner class to create the target runnable and hide the public run method- An inner class Is s claw nested or delined Inside another class, and hiding the put 
implementation in an mner class like this prevents external code from erroneously calling It. Because the 7 un method is public, using an inner dass is safer than having the ft-'UdtSncw da 
:. ..iinvii/i-s interlace and providing the method implementation as peri ol the siid^inc-v ctass like this: 

An Interface defines a sei ol methods but does not Implement their behavior. Insteed. you provide the interface method implementations for the dass that implements the interlace. The f.uj 
provides the j meihod as a common protocol tor a ctass instance to execute a separate thread of code. Your implementation for the v . = ; method defines what the separate thread of e« 
In this example, the method implementetion calls the lunwovi: method described in Running Tne Timer Thread below. 

Using the f u-m-u; ; interlace is one ol two approaches available In the Java programming language for writing multi-threaded program. The other approach is to extend the Thi e«c class 
the RvmifctJ ~ interface. However, because the Java programming language does not let you extend more than one class, extending the s "V. .r dass has its limitations when you need tc 
extend the Ai,; J * : dass to write an applet or extend the Ft arat class to write an application with a graphical user interface. For this reason, using the kynn&Li* intertsce Is the more com 

The wait-notify mechanism is used to keep the t i:ct: Thr^ci in the paused state until the applet's * *:t -.t -i. method Is called. The wait-notify mechanism allows one thread to wait lor a notifi 
thread that it can proceed. The -> . . : variable is set to u in the sr.* r Th ci method and checked by the t i r threed when the : method is ceiled. Calls to the applet's & r r 
toggle the ptv «-.-:': variable between ;«« t * and ».ru*. respectively. 

Note that the -.a . -instance variable set to ibl&s In the eieri.Thr i-aci method is dedared vt-i3ti3o. The vj hu ■ i , modiher requests the Java VM to always access the 

variable so the its most current value is always read. Making z t.ni.*e«uc sr.ni volatile is necessary so other threads see the changed value. In this example r^: «a 5 aj.-plct.-3J i 3*:Si 
changes the value in its ■ and s •.(•jr,Thr*aii methods and the Timer thread reads the value in its run method. 

Note: it ts important to understand when to use the vcly t i j c modifier, and (here are some rule you can follow. To quote a section from Java Thread Programming: The Aulhoi 
Solution by Paul Hyoe: 



two or more threads access e member variable, and 

one or more threads might change that variable's value, and 

ell ol the threads do not use synchronization (methods or blocks) to resd and/or write the value. 
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then 

that member variable must be electa red • ■ ■ ■ ; • tc ensure an threads see the changed value. 
See Pausing me Aor**ei tor information on using synchronization. 



Running The Timer Thread 

The runv.c rv method moves into a --.-= ; loop il no stop has been requested end stays in the loop until the applet's su*/ri-.ro#».d method is called where the • ; . v*. » i -^i 
veriabte is set tc :.'ai?»- . inside the loop the '.j w/:^ . j method is called to keep the applet in e paused state It the p*x*-*v. instance variable has a vatue ot • 

When the applet tirst starts, its t-au*. variable is initialized to v h and chenged to tm when the Ft« method rs called. It is also set to t.rj* when the applet's .w method Is 
called. So the 7 i r^v thread sits in the >v loop waiting tor the applet's a tivv. and su-?: methods to set the values tor the p&ussd variable. 



When paused ts set to t a*, the " ir^r thread retrieves images and captions trom their anays and calls the repei nt method to update and paint the applet's panel. Between calls 
to the i&zaiTix. method and retrieving the next image and caption, the thread sieeps tor 3 seconds so each image In the slide show can stay on the display ror viewing. 

The pi-;?:;., method throws 3 /»t<sr rucU':Ext-:-»ffi.<-;n. which is raised when l. ;.: ^ ■:"):: (■..%■: . interrupt is called trom the sLcpThrttci method. The :$U'j:T:.j:-jt.£ method is called 
by the applet* ■>.**- i.i .*: v method when the applet exits. The interrupt causes the r ; thread to move out ot sleep mode and jump to the cbi.c'r. Woe* where the interrupt is 
reasserted, a message is printed, and the thread dies. 

Note that the cuvf-j v^-v Instance variable is declared ^i&i \ j . j - because it is updated by the r^nw..i .< method in the Tin** thread and read by the -rM*t.c method in t.nr*&n 



/ Nt.-t--? i-Mx 




The call to rr - n: v)*.;. .. ^ *:% :.; ; ; at the beginning gets the name ot the current thread and prints it to the command line. The sample run above shows that at this point in the applet's 
execution the current thread is the T ir.^r thread: 



Pausing the Applet 

The mechanism tor pausing the applet consists of the ;;.i;:i;tti. ;:.>. object, instance variable, a^tPtve^i method, end waiuihiifcPauBfc-5 method. The ^.iis^t. ; instance 

variable is not declared v - i * because all threads that update or read it use synchronization. 

Synchronization lets one thread safety change values that another thread reads. The set raue-ei: method executed by th: &j..pirct - si i 4e?h<:w. cierti toggles the peue-erf 
variable between and : ; ist according to whether the applet is In e stopped, started, or initialized but not yet started stele. The v3itWfciItPau«^j method executed by Ihe 
?:.R>«r thread reeds the value end Keeps the applet in a paused state when the ttwsoti value is set to u u* end in en urv paused state when the pbussu" value changes to I'd J .s*. 
Because both these methods use synchronization, the »ai twh : i ^p-auk*: method cannot read the value of the i^hk* -z verieble until the u*:t.Pfcx,-«*:! method finishes setting it end 
vice versa. 

When the Tinev thread calls v-.i vW; ; ; lc> eu. ■ It synchronizes on r*ua'.;u;c* and reeds the value ol pau**a. II the value Is true, y-aus*^:* .w*i*. is called and the Tux+r 
thread goes to sleep. What is happening is the r i t,.h t thread is waiting on the object to prevent the v& a t tfh i 2 e p&uied method Irom returning, it the value is lei--..-, the 

*h i 3 e loop in the T : at.- thread continues to execute. 

It the i iTwi- thread is put to sleep, it stays asleep until it is either interrupted or notified by the set-feuta* method that poue &<J is now iai s». When th *j -pJ e t 

s ■ ifleS'i -w. v-.'.uss calls xt-Pa ».=.:. it synchronizes on pft'jstfi^-vi. changes the value ot i-dueto, notifies all waiting threads the value has changed, exits ihe synchronized block. 

and returns. When the Ti r v.r thread receives the notification, it wakes up. exits its synchronized block, end returns Irom the *ai t -whi i«p«u««d method. 
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Object-Level Locks 

When code synchronizes on en object. It acauires en object -level lock on that object. This means no other thread can call methods on that object until the toe* is releasee 

The v- v _ . methods ol the tv^c^'t class require that an object-level toe* be held before they ere called. Very soon atter the thread sets inside the native code of the r*x>:. method, the 
Java VM releases the tock that thread was holding. Once the waiting thread is notified, times out. or is interrupted, it competes wtth other threads to reacquire the object-level lock. Once 
the thread has exclusive access to the object-level lock, it returns from the ^; :■■ method anc continues inside the synchronized block. 

A thread must hold an object-tevel tock on the object before it can call any of the ^ : -\ . y . or : * : v*i : methods on that object. Once a thread gets inside waii:. the Java VM 
temporarily releases the lock to ensure that the signaling is solid and not open to any race conditions. And it the waiting thread did not release the lock, another thread would not be able 
tc cat! ■ ■ : - ■ \'i> or n:.-i. ; f wV. j because tt would not be able tc get the lock. 

Updating and Painting the Display 

The -i «vt v. i method called from within the wr; method repaints the applet's panel and calls the applet's = - i.r-^ method to completely redrew the applet* panel. 

'':i.:>»'.i . ~ T'i'.r^atl . cur r*:"?.-r?.-j .u-u-'i i) : 

■' . 'jravfL-fsyi; i irr-fccjos f ciiTraM: j . , 0, v. his ; ; 
;a::t.: . sntText ; t-f^ct ;::;;riJir^i i ; 
: :h*w:: i --• Tr.rt-fl.-j. rrir ? [-Thr -?h;1 i) ; 

The can to : ; ! ~ r.i t .r.JNar-; at the beginning gets the name of the current thread and prints it to the commend line. The sample run above shows that at this point in the applet's 
execution the current thread is the AWT- E vent Queue-O thread: 

A in - £ v kt: '■: €- 1 : «4 ■- C 

Stopping the Applet 

The applet's . method is celled whenever you minimize applet viewer, or it the applet is running in a Web page, whenever you go to another Web page. At this point the 
;.•>;■.:■-■■:: method is called to put the applet in a paused state. 

The last tine or the sf-p method calls pr; n tTnr«adKar>£ to get the name ot the current thread and print It to the command line. The sample run above shows that at mis point in the 
applet's execution the current thread is the the applet thread: 

;-v. '!« t r.'rar; ar;-j • ■ i^*»?h*v.'. clans 

Exiting the Applet 

When you exit applet viewer or close the browser, the applet's dest vcy method is called to stop the thread and perform cleanup. The image and text arrays are set to t^: i to make 
them reedy tor garbage collection. 

The call to Sr^c^s si.: i flushes all resources used by the array, including any pixel data being cached for rendering to the screen and any system resources used to 
store data or piiete lor the images. The images are reset to a state similar to when they were first created so that il they are rendered again, the image date has to be recreated or 
fetched from fts source. 



< -..f-;.7 { I .- 

!:,:■.; ; • ■ : > ; . *. \ !?4i£C->< . i i'Hy XT. ; 
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The iast tine c' the " ::■:*/ method calls the pri^tThr aacfrifcT.*: method to get the name ol the current Thread end print the name to the command line. The sample run above shows 
thai at thi& point in the applets execution the current thread is the the applet thread: 



Conclusion and Further Reading 

— : While it is relatively easy to gel started with mufti -threaded programming in the Java programming language, mastering the use of multiple threads 
] and establishing communications among them takes time, practice, and patience. An examples-based approach Is one of the best ways lo learn 
because you reinforce what you read by putting the concepts into practice. 



dsn Rtratf 



An excellent examples-based reference is Java Thread Proerefr.rntng. t he Authoritative Solution t>y Paul Hyde. This is en accessible and complete 
treatment that inexperienced and experienced developers eTike should find worthwhile. 

The Doing Two cr More Tasks at Once lesson In The Java Tutorial provides excellent Introductory coverage as well. 
Also see Concurrent Programming in Java by Doug Lee one visit his web site. 



Monica Ps «riar 7 a staff writer tor the Java Developer Connection (JDC), Is author of Essentials ot the Java Programming Language: A Hanas-On Guide (Addison- Wesley. 2000), end 
co-author of Advanced Programming for the Java 2 Platform (Addison- Wesley, 2000). 

Have a Question about programming? Use Java Online Support. 



1 As used on this web site, the terms 'Java virtual machine" or "JVM" mean a virtual machine tor the Java platform. 
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